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Preface 


This  is  the  second  edition  of  the  SEI  Technical  Report,  An  OOD  Paradigm  for  Flight 
Simulators,  which  was  first  issued  in  December,  1987.  We  have  issued  this  edition  to  report 
modifications  we  made  to  the  paradigm  while  preparing  for  a  tutorial  given  at  the  March, 
1988  AdaJUG  in  Phoenix,  AZ. 

The  paradigm  is  being  used  by  SEI  affiliates  on  full-scale  devlopment  programs.  The  SEI 
project  team  supports  the  use  of  the  paradigm  by  consulting  with  the  affiliates.  The 
affiliates’  efforts  improve  the  paradigm  by  tailoring  it  to  the  nuances  of  particular  programs. 

This  report  does  not  describe  all  the  ways  the  paradigm  has  been  tailored  to  fit  specific 
programs.  The  results  of  those  efforts  will  be  documented  in  subsequent  versions  of  this 
report.  Some  of  the  more  substantial  changes  are  treated  as  Open  Issues  in  Section  6  of  this 
edition. 
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1.  Introduction 


1.1.  Abstract/Backgroimd 

This  report  presents  a  paradigm  for  object-oriented  implementations  of  flight  simulators.  It 
is  a  result  of  work  on  the  Ada  Simulator  Validation  Program  (ASVP)  carried  out  by  members 
of  the  technical  staff  at  the  Software  Engineering  Institute  (SEI). 


1.2.  Motivation 

Object-oriented  design  (OOD)  predominates  discussions  about  Ada-based  software  engineer¬ 
ing.  The  identification  of  objects  and  the  implementation  of  objects  are  two  separate  issues. 
This  paradigm  is  a  model  for  implementing  systems  of  objects.  The  objects  are  described  in  a 
form  of  specification  called  an  object  diagram.^  The  paradigm  is  not  about  how  to  create  the 
specification. 

Although  much  has  been  written  on  object-oriented  design,  SEI  project  members  could  find 
no  examples  of  object-oriented  implementations  relevant  to  flight  simulators.  Examples 
were  required  for  two  reasons.  First,  object-orientation  was  new  to  both  of  the  contractors  on 
the  ASVP.  A  methodology  which  leads  to  a  specification  of  objects  is  useful  only  if  developers 
know  how  to  implement  what  is  specified.  Second,  managers  were  skeptical  about  the  bene¬ 
fits  of  object-oriented  design.  Examples  were  needed  to  determine  whether  benefits  out¬ 
weigh  costs. 

The  intent  of  our  work  was  to  produce  examples  of  object-oriented  systems.  It  was  not  our 
intent  to  determine  whether  object-oriented  design  was  best  for  flight  simulators.^ 


^See  Chapter  4  and  Figure  4-2  for  an  example  of  an  object  diagram. 
^See  Section  2. 1  for  some  historical  motivation. 
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1.3.  Characteristics  of  the  Application  Domain 

The  paradigm  was  developed  for  a  specific  application  domain,  namely  flight  simulators  and 
training  devices.  This  section  puts  the  paradigm  in  context  by  briefly  describing  the  relevant 
features  of  the  application  domain. 

The  objective  of  a  flight  simulator  is  to  reproduce  on  the  ground  the  behavior  of  an  aircraft  in 
flight.  Simulators  are  used  to: 

•  train  aircrew 

•  train  maintainers  of  aircraft 

•  aid  designers  of  aircraft 

A  training  simulator  consists  of  a  mock-up  of  stations  for  the  aircrew  being  trained.  The 
mock-up  contains  the  controls  available  to  manipulate  the  aircraft  and  systems  for  cuing  the 
operator  to  the  aircraft^s  response  to  his  actions.  Cues  include  gauges,  video,  sound,  and 
motion. 

The  training  mission  is  set  by  an  instructor  at  an  Instructor  Operator  Station  (lOS).  Some  of 
the  factors  set  by  the  instructor  are  longitude,  latitude,  altitude,  and  atmospheric  conditions. 
Instructors  also  affect  the  behavior  of  the  simulator  by  introducing  aircraft  malfunctions. 

The  ASVP  focused  on  software  that  models  the  behavior  of  major  systems  affecting  an 
aircraft^s  flight:  the  airframe,  the  engines,  the  electrical  system,  the  fuel  system,  the 
hydraulic  system,  and  others. 

Traditionally,  this  software  is  put  under  the  control  of  an  executive  which  periodically  up¬ 
dates  systems.  Flight  simulators  are  not  event-driven.  Interaction  between  systems  in  the 
real  aircraft  are  continuous.  Simulators  model  those  interactions  in  discrete  time. 

Time  constraints  are  normally  tighter  than  memory  constraints.  Multiple  processors  are 
used  to  distribute  processing  and  to  link  the  software  to  hardware  in  the  aircrew  training 
station.  Trends  are  such  that  multi-processor  architectures  are  becoming  more  prevalent  in 
the  domain. 

Flight  simulators  are  long-lived  and  frequently  modified.  The  two  major  modifications  are 
changes  to  the  aircraft  itself  which  must  be  reflected  in  the  simulator  software  and,  secondly, 
changes  in  the  training  missions.  T3q)ical  of  the  latter  are  the  addition  of  new  malfunctions. 

Flight  simulators  are  based  on  math  models  provided  by  the  manufacturer  of  the  aircraft 
components  in  the  actual  aircraft.  The  ultimate  test  of  the  simulator  is  the  way  it  feels  to 
aircrew  experienced  with  the  aircraft  being  simulated.  The  process  of  tuning  the  feel  of  the 
simulator  is  called  aircrew  tuning. 

Flight  simulators  provide  natural  opportunities  for  reusing  software.  First,  different  aircraft 
have  the  same  kinds  of  components,  e.g.,  engines,  fuel  systems,  electrical  systems,  etc. 
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Sometimes  a  particiilar  instance  of  a  kind  of  component,  a  Pratt  and  Whitney  engine  for 
example,  is  used  on  a  variety  of  aircraft.  Second,  the  three  classes  of  simulators — training, 
maintenance,  and  engineering — model  the  same  components  to  varying  degrees  of  fidelity. 
Third,  a  simulator  is  made  up  of  systems  that  can  be  viewed  identically  at  some  level  of 
abstraction. 


1.4.  Reader’s  Guide 

This  report  contains  the  work  completed  to  date,  presents  the  paradigm,  and  discusses  the 
advantages  of  the  paradigm.  It  is  meant  to  stand  on  its  own  merits.  The  model  we  have 
developed  solves  a  specific  set  of  problems.  We  do  not  claim  it  to  be  the  only  model  for 
solving  these  problems.  The  paradigm  uses  many  of  the  characteristic  software  engineering 
concepts,  but  the  report  is  not  intended  to  be  a  report  on  software  engineering  theory.^ 

The  next  chapter  discusses  our  approach  to  developing  the  paradigm  and  how  we  assessed 
the  fit  of  our  solution  to  the  problem  at  hand. 

Chapter  3 

introduces  the  conceptual  elements  of  the  paradigm  and  provides  an  overview  of  the 
software  structure  implied  by  the  paradigm. 

Chapter  4 

presents  a  detailed  view  of  the  elements  of  the  paradigm.  The  elements  are  presented 
bottom-up  using  an  Engine  system  as  an  example.  Each  section  on  a  particular  ele¬ 
ment  ends  with  a  discussion  of  the  benefits  of  the  implementation  chosen  for  the  para¬ 
digm.  The  final  section  of  Chapter  4  summarizes  the  benefits  of  the  paradigm. 

Chapter  5 

discusses  the  role  of  a  paradigm  in  the  development  process. 

Chapter  6 

discusses  issues  which  we  have  thought  about  during  the  development  but  have  not 
had  time  to  fully  address. 

Chapter  7 

is  a  very  brief  presentation  of  a  simulator  Electrical  system. 

Appendix  A 

describes  a  modified  form  of  the  notation  expoimded  by  Grady  Booch  in  his  book  on 
software  engineering  with  Ada  [1]  and  his  book  on  reusable  software  components  with 
Ada  [2].  The  notation  is  used  in  the  diagrams  in  Chapter  3. 

Appendix  B 

contains  an  object  manager  template.  The  use  of  reusable  code  templates  is  discussed 
in  Chapter  5. 

Appendix  C 

presents  a  version  of  the  Engine  system  code  complete  through  the  package  specifi¬ 
cations.  The  intent  is  to  demonstrate  the  software  architecture  defined  by  the  object 
paradigm  discussed  in  Chapter  4. 


the  audience  perceives  that  this  report  woTild  be  useful  within  a  tutorizd  on  software  engineering,  we  invite 
such  a  use  of  the  report. 
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2.  Approach 


2.1.  History 

The  project  team  began  the  search  for  a  paradigm  after  reviewing  an  implementation  of  an 
electrical  system  done  by  one  of  the  contractors  on  the  ASVP.  The  implementation  was  more 
data-oriented  than  object-oriented.  The  implementation  was  a  definite  improvement  over 
the  original  FORTRAN  implementation.  However,  the  team  did  not  consider  the  implemen¬ 
tation  to  be  exemplary. 

The  project  team  decided  to  spend  what  it  thought  would  be  no  more  than  a  month  or  two 
developing  an  example  of  a  pure  object-oriented  design  of  an  electrical  system.  A  circuit 
diagram  was  used  to  identify  the  objects  and  the  relationships  among  the  objects.  The  be¬ 
havior  of  the  objects,  e.g.,  circuit  breakers,  relays,  and  batteries,  and  of  circuits  in  general, 
was  well  understood. 

Material  available  to  us  on  object-oriented  design  did  not  adequately  address  connections 
among  objects  or  updating  systems  of  objects  in  discrete  time. 

The  project  team  implemented  an  object-oriented  electrical  system  which  came  close  to  satis¬ 
fying  the  goals  described  below.  At  that  time  one  of  the  contractors  on  the  ASVP  asked  the 
project  team  to  sketch  out  an  object-oriented  implementation  of  an  engine.  The  team  ob¬ 
served  that  the  object-oriented  implementation  of  an  engine  and  of  an  electrical  system  were 
identical  at  some  level  of  abstraction. 

The  project  team  decided  to  capture  the  similarities  in  a  paradigm  for  object-oriented  sys¬ 
tems.  The  paradigm  was  to  dictate  how  an  object-oriented  specification  would  be  imple¬ 
mented  in  software  and  how  the  update  of  systems  would  be  controlled.  The  drive  to  gener¬ 
alize  uncovered  flaws  in  our  designs  of  both  the  engine  system  and  the  electrical  system. 

The  project  team  did  not  develop  the  paradigm  methodically.  We  were  not  interested  in 
testing  design  methods.  Our  goal  was  to  produce  a  paradigm  for  object-oriented  systems. 
We  did  not  want  to  limit  our  search  space  to  architectures  produced  by  known  methods. 
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2.2.  Design  Goals 

The  project  team  began  with  two  basic  goals.  One  was  to  eliminate  nested  implementations 
of  objects.  The  other  was  to  simplify  dependencies  among  objects. 

2.2.1.  Nested  objects 

Nested  objects  result  from  decompositional  approaches  that  purport  to  help  the  designer 
discover  which  objects  are  needed  to  implement  a  system.  For  example,  the  designer  begins 
with  the  notion  of  an  engine  as  a  black  box.  All  interfaces  to  the  engine  appear  at  the  surface 
of  the  black  box.  Now,  suppose  the  vibration  of  an  engine  compressor  needs  to  be  metered. 
The  designer  decides  to  decompose  the  engine  into  other  objects,  one  of  which  is  a  compres¬ 
sor.  Access  to  the  vibration  level  of  the  compressor  passes  through  two  levels:  the  engine 
level  and  the  compressor  level.  Further,  decomposition  might  lead  to  modeling  each  stage  of 
the  compressor  as  an  object,  thus  adding  a  third  layer  to  the  nested  object.  Finally,  black  box 
implementations  require  knowledge  of  the  entire  black  box,  even  when  only  one  state  or 
aspect  of  the  black  box  is  used. 

Nested,  hierarchical  objects  do  have  advantages.  First,  it  should  be  possible  to  update  a 
composite  object,  such  as  an  engine,  as  if  it  were  a  black  box.  Second,  it  should  be  possible  to 
reuse  an  object,  such  as  an  engine,  as  a  separate  entity. 

2.2.2.  Object  dependencies 

Figure  2-1  shows  a  dependency  between  objects  A  and  B,  In  this  example,  B  provides  A  with 
something.^  Thus  the  state  of  A  depends  on  the  state  of  B.^  There  are  several  ways  for 
handling  this  dependency.  One  common  method  is  to  have  the  implementation  of  object  A 
with  object  B.  When  A  is  updated,  A  reads  the  relevant  state  of  B.  This  method  does  not  work 
if  B  and  A  are  on  separate  processors.  Even  if  A  and  B  are  on  the  same  processor,  it  is  never 
clear  which  object  should  define  the  dependent  data  type. 

Another  common  solution  is  to  have  object  B  call  object  A  and  report  its  state.  This  solution 
introduces  a  new  problem  without  solving  the  problem  mentioned  above.  If  the  flow  between 
B  and  A  is  continuous,  then  it  is  unnatural  for  object  B  to  model  discrete  time  by  controlling 
the  rate  at  which  A  is  updated.  Further,  if  B  and  A  are  part  of  a  closed  feedback  loop,  the 
update  cycles  indefinitely. 


*The  same  diagrammatic  notation  is  used  throughout  this  report.  The  arrows  represent  dataflows.  Thus 
something  is  needed  by  the  object  at  the  head  of  the  arrow  and  is  supplied  by  the  object  at  the  tail  of  the  arrow.  The 
arrow  is  labeled  with  the  data  near  its  tail. 

®In  Ada,  an  object  which  depends  on  another,  separately  compiled  object,  uses  the  with  clause  to  gain  visibility  of 
the  dependent  object.  The  object  is  said  to  with  the  dependent  object. 
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Figure  2-1:  Object  Dependency  Example 


2.3.  Evolution  of  the  Paradigm 

Designers  talk  about  the  fit  of  a  design  to  its  context,  the  problem  space.  The  criteria  for 
assessing  the  fit  of  solutions  to  complex  problems  often  can  be  determined  only  in  response  to 
a  proposed  solution  and  cannot  be  determined  before  solutions  are  generated.  Such  was  the 
case  for  the  paradigm. 

Our  team  began  with  intuitive  feelings  about  the  standard  goals  of  software  engineering, 
such  as  modularity,  ease  of  enhancement,  and  reuse.  The  paradigm  passed  through  several 
iterations  within  the  team.  Each  iteration  left  a  legacy  of  criteria  for  assessing  the  fit  of  the 
solution  for  the  paradigm. 

For  example,  the  model  for  object  managers®  and  a  means  for  connecting  objects  surfaced  in 
the  first  version  of  the  paradigm.  The  objects  stood  alone,  and  were  not  dependent  on  Ada 
types  declared  elsewhere.  This  enhanced  the  reusability  of  the  object  managers  and  facili¬ 
tated  independent  development.  The  means  for  connecting  objects  had  an  intuitive  analog  in 
the  real-world.  Pipes  and  wires,  connecting  objects  in  the  world,  are  as  real  as  the  objects 
themselves  auid  would  not  be  subsumed  in  software  by  the  implementations  of  the  objects. 

Since  the  first  edition,  the  notion  of  a  connection  has  changed.  Conduits,  e.g.,  the  Engine 
Casing  in  the  Engine  system  (see  Chapter  4),  or  wires  in  the  Electrical  system,  can  have 
states  just  like  other  objects  and  might  need  to  retain  information  about  previous  states  like 
other  objects.  Futhermore,  these  "connecting"  objects  could  be  in  a  malfunctioning  opera¬ 
tional  state  like  other  objects.  Therefore,  this  kind  of  object  is  now  considered  equivalent  to 
other  objects.  The  abstraction  which  is  now  called  a  connection  merely  transfers  data  be¬ 
tween  any  two  objects.  A  connection  does  not  have  an  analogy  in  the  physical  world;  it 
merely  implements  an  arrow  on  the  object  diagram.  Figure  4-2. 


Object  xxianagers  are  introduced  in  Chapter  4. 
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Also,  after  issuing  the  first  edition,  we  determined  that  the  distinction  we  had  made  between 
systems  and  subsystems  was  not  necessary.  Thus,  the  notion  of  a  subsystem  has  been 
eliminated. 

The  chapters  which  follow  discuss  the  advantages  of  the  paradigm.  We  did  not  set  out  to 
obtain  these  advantages.  The  advantages  revealed  themselves  as  the  work  progressed.  An 
advantage  which  revealed  itself  in  one  iteration,  was  retained  as  a  criterion  for  evaluating 
the  fit  of  subsequent  iterations. 
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3.  Concepts  Used  by  the  Paradigm 


This  chapter  provides  a  brief  description  of  some  of  the  concepts  introduced  with  the  para¬ 
digm  and  a  high  level  overview  of  the  software  architecture  defined  within  the  paradigm. 
The  concepts  are  further  elaborated  in  Chapter  4. 

The  paradigm  described  in  this  report  begins  with  the  notion  of  an  executive.  An  executive 
controls  the  update  of  a  set  of  systems  compiled  together  running  on  a  single  processor.  The 
paradigm  assumes  that  there  will  be  more  than  one  set  of  systems  and  that  multiprocessing 
will  be  involved. 

Communication  between  executives  is  handled  by  an  abstraction  called  a  buffer,  A  buffer  is 
some  means  of  sharing  data  among  separately  compiled  software.^  The  paradigm  makes  no 
assumption  about  how  the  operating  system  transfers  data  or  how  executives  on  separate 
processors  are  invoked. 

The  fundamental  units  of  the  paradigm  are  objects  and  connections.  Objects  map  to  real- 
world  entities.  An  object  is  implemented  as  a  math  model  that  maps  the  environmental 
effects  on  the  object  to  the  object’s  outputs,  given  the  attributes  of  the  object  and  its  opera¬ 
tional  state.  The  implementation  isolates  individual  effects.  Also,  an  object  is  not  aware  of 
its  connections  to  other  objects. 

A  connection  is  the  mechanism  for  transferring  state  information  between  objects.  Proc¬ 
essing  a  connection  involves  reading  the  state  of  some  objects  on  the  connection  and  broad¬ 
casting  to  others. 

At  all  levels,  updates  are  accomplished  by  gating  (or  processing)  the  appropriate  connections. 
The  levels  discussed  in  the  paradigm  are  system  and  executive,  A  system  is  an  aggregation  of 
objects®  and  the  connections  among  those  objects.  An  executive  is  a  set  of  systems  and  all 
connections  that  cross  system  boundaries,  i.e.,  connections  between  objects  in  different  sys- 


^In  our  observations  of  flight  simulators,  a  buffer  is  a  record  data  structure  used  in  the  communication  between 
processors. 

®The  aggregation  is  a  matter  of  convenience.  The  objects  are  aggregated  because  they  cooperate  in  performing 
common  goals. 
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terns.  Figure  3-1  shows  views  of  an  executive,  two  systems,  and  several  objects  and  connec¬ 
tions.  - — — — - 


Executive-level 


Executive  is  :  System  1,  System  2,  and  connections  a  and  e 
System  1  is  :  Objectsi,  2,  and  3,  and  connections  b  and  d 
System  2  is  :  Objects  4,  5,  and  connection  c 

Figure  3-1:  Object  Diagram  Example 


3.1^  Overview  of  the  Software  Architecture 

3.I.I.  The  Executive  Level 

Figxire  3-2  shows  the  executive-level  software  architecture.^  In  this  case,  we  assume  an 
executive-level  called  Flight_Executive.  The  body  of  the  Flight_Executive  package  contains  a 
tabular  schedule  of  systems  to  update.  The  names  of  the  S3rstems  are  declared  in  the  pack¬ 
age  Fhght_System_Names,  the  sole  purpose  of  which  is  to  enumerate  the  names. 

Each  system  is  represented  by  a  package  called  <system_naine>_System.^®  The  specifi- 


See  Appendix  A  for  a  deacription  of  the  icons  used  in  Figures  3-2,  3-3,  and  3-4.  The  arrows  on  the  diagrams 
represent  (wUhiitg)  dependencies.  The  shaded  portiona  of  each  icon  represent  the  package  body,  the  white  portions 
the  package  specification.  Note  that  the  dependencies  originate  within  package  b^es.  This  reduces  the  need  for 
widespread  recompilation  in  the  event  of  a  change. 

'®The  use  of  "<...>"  within  subprogram  names,  type  names,  or  text  refers  to  a  general  case  of  the  item.  For 
example,  <aystem_name>.Sy8teni,  is  a  general  form  representing  all  instances  of  the  package  name,  e.g., 
Engine^System,  Elec trioal_Sys  tern,  Fuel^Systexn,  etc.  See  Chapter  6  for  a  more  detailed  discussion  and 
examples  of  the  use  of 
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Fllgh!__Ex©cutlv0 


Flloht  Exocuttv#  ^Connections  Englno_Systom 


Electrtcal.System  Fu«l\y5tom 


•  •  • 


Figure  3-2:  Executive  Level  Software  Architecture 

cation  of  a  System  package  exports  a  single  procedure  which  is  called  by  Flight_Executive  to 
update  a  system. 

The  connections  belonging  to  the  executive-level  are  managed  by  an 
<executive_iiame>_Connections  package,  in  this  case,  Flight_Executive_Connections. 
The  architecture  from  the  perspective  of  the  connection  package  is  shown  in  Figure  3-3. 

Fllg  ht_Ej(ecuttv«_Conn®ctk)os 


OM  -  Objoct^Mcmager 

Figure  3-3:  Connection  Manager  Software  Architectvire 


The  body  of  the  connection  package  is  a  series  of  separate  procedures,  one  for  each  system 
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under  the  control  of  the  executive.  Each  separate  procedure  is  responsible  for  gating  all  the 
executive-level  connections  to  a  system. 

3, 1.2.  The  System  Level 

Figure  3-4  shows  the  architecture  from  th^  ^'*rspective  of  a  system,  using  the  Engine  system 
as  an  example.  Objects  in  a  system  are  created  and  named  by  the 
<system_naine>_System_Aggregate  package.  Objects  are  managed  by 

<object_name>_Object_Maiiager  (OM)  packages. 


Englfw^Systom 


1 


Englno^System^Aggregate  Englna^SystomjConnoctlons 


Figure  3-4:  Sjrstem  Level  Architecture 

3.1.3.  Overall  Software  Architecture 

The  overall  software  architecture  is  shown  in  Figure  3-5.  The  executive-level  consists  of  the 
Flight_Executive  package  and  the  Flight_Executive_Connection8  package.  The 
system-level  consists  of 

•  <8y8tem_name>_Sy8tem  package 

•  <8y8tem_name>_Sy8tem_Coimection8  package 

•  <8y8tem_name>_Sy8tem_Aggregate  package 

The  complete  systel-level  architecture  of  the  Engine  system  is  shown.  The  architecture  of 
the  other  systems,  e.g.,  the  Fuel  system  and  the  Electrical  system,  would  be  similar. 

Each  connection  package  is  "nested"  within  the  corresponding  system  or  executive  packages. 
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Each  connection  within  the  connection  packages  is  distinct,  embodied  within  a  separate  pro¬ 
cedure. 

There  is  one  object  manager  package  per  object.^^ 


Flight_Exacutive 


Fligh  t_E  xecutive_Connections  Engin«_Systefn 


ElactricaJ_System 


Fud_System 


OM  a  Object^Manager 


Figure  3-5;  Overall  Software  Architecture 


^^Not«  the  object  managers  have  no  dependency  on  other  modules. 
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4.  Paradigm  Description 


The  example  used  to  illustrate  the  paradigm  is  a  turbofan  engine.  Engines,  in  flight  training 
simulators,  interact  with  a  variety  of  other  systems  on  the  aircraft,  including  the  Fuel  sys¬ 
tem,  the  Oil  system,  the  Starter  system,  the  Electrical  system,  and  the  Hydraulic  system. 
The  engines  also  provide  bleed  air  for  Cabin  Pressure  and  Air  Conditioning  systems. 

Section  4.1  describes  the  engine  components  and  the  interaction  of  the  engine  with  the  other 
aircraft  systems  and  the  outside  environment.  The  following  section.  Section  4.2,  describes 
the  Engine  object  diagram  and,  briefly,  the  meaning  behind  each  icon  on  the  diagram.  The 
rest  of  the  chapter  introduces  the  paradigm  by  discussing  the  implementation  of  the  Engine 
system. 


4.1.  Engine  Description 

Figure  4-1  shows  a  diagram  of  a  turbofan  engine  with  the  relevant  parts  labeled.  The 
Engine  Casing  encloses  the  other  engine  parts  and  provides  the  conduit  through  which  the 
air  flows  as  it  interacts  with  the  other  parts.  Air  enters  the  Diffuser  at  some  temperature, 
pressure,  and  flow  rate.  The  Fan  Duct  directs  part  of  the  air  flow  out  of  the  engine  to 
provide  some  thrust  to  the  Airframe  system  of  the  aircraft.  The  initial  set  of  blades  on  the 
two  Rotors  adds  energy  to  the  air  by  compression.  The  Burner,  or  combustion  chamber, 
adds  more  energy  to  the  air  by  mixing  fuel,  from  the  Fuel  system,  with  the  air  and  igniting 
the  mixture  with  a  spark  from  the  Ignition  system.  The  second  set  of  blades  on  the  Rotors 
removes  some  energy  from  the  air  to  turn  the  Rotor  shafts  and  their  initial  set  of  blades. 
Finally,  the  Elxhaust  provides  additional  thrust  on  the  Airframe  system. 


4.2.  Engine  Object  Diagram 

The  Engine  object  diagram  in  Figure  4-2  is  another  representation  of  the  Engine  shown  in 
Figure  4-1.  All  the  functionality  apparent  from  Figure  4-1  is  evident  in  Figure  4-2.  In 
addition,  the  Engine  object  diagram  identifies  the  objects  which  comprise  a  generic  turbofan 
engine  and  the  engine’s  relationship  with  the  outside  environment.  The  correspondence  be¬ 
tween  the  real-world  components  of  the  engine  and  the  object  components  in  the  object 
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Roton  Rotor2 


Diffuser  Fan  Duct 


Burner 


Engine 


Casing 


Exhaust 


(Bleed  valve  —  not  shown) 


Figure  4-1:  Turbofan  Engine  Description 

diagram  represents  the  first  of  two  meanings  for  object-orientation  in  this  solution.^^  The 
choice  of  objects  may  not  be  ideal  but,  for  the  purposes  of  the  discussion  in  this  report,  this 
set  of  objects  is  acceptable.  (The  Engine  object  diagram,  Figure  4-2,  will  be  referred  to 
throughout  the  rest  of  this  chapter.) 

There  are  four  icons  on  the  object  diagram  to  represent  four  kinds  of  entities — objects,  con¬ 
nections,  systems,  and  executives. 

The  square  boxes  within  the  rectangle  represent  the  engine  objects.  The  olgects  are; 

•  Diffuser 

•  Rotorl 

•  Fan  Duct 

•  Rotor2 

•  Burner 

•  Bleed  Valve 

•  Exhaust 

•  Engine  Casing 

The  function  of  the  objects  is  to  map  their  inputs  to  their  outputs.  Objects  in  the  real-world 
know  nothing  of  their  environment,  neither  the  objects  which  depend  on  them  nor  the  objects 
upon  which  they  depend.  We  model  objects  the  same  way. 


^^The  second  meaning  for  object  orientation  is  described  in  Section  4.3. 
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Instrumentation 

System 


Figure  4-2:  Turbofan  Engine  Object  Diagram 
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System 


The  Engine  Casing  object  is  the  object  through  which  the  air  flows  as  the  air  passes 
through  the  engine.  Each  object  has  some  dependency  on  the  air  flow,  as  it  passes  through 
the  Engine  Casing,  denoted  by  the  arrows  between  the  Engine  Casing  and  the  other 
objects  Thus,  the  Rotorl  Fanl  Inlet  air  pressure,  temperature,  and  flow  comes  from  the 
Engine  C'^  sing.  Also,  each  object  has  outputs  needed  by  the  Engine  Casing,  e.g.,  the 
Rotorl  Fanl  Discharge  air  pressure,  temperature,  and  flow  are  available  to  the  Engine 
Casing. 

Each  engine  object  in  the  Engine  object  diagram  interacts  with  its  external  environment  as 
defined  by  the  diagram.  No  other  dependencies  on  the  outside  world  should  be  necessary 
except  for  those  shown  in  the  diagram.  The  diagram  serves  as  a  specification  for  the  Engine 
system  interfaces.  Given  such  a  diagram  and  the  paradigm  description  that  follows,  the 
design  of  the  Engine  system  is  complete. 

The  arrows  represent  connections.  A  connection  moves  information  between  objects.  An 
arrow  points  in  the  direction  of  data  flow,  e.g.,  a  datum,  called  mach  number,  flows  from  the 
Airframe  system  to  the  Diffuser  object,  and  other  information  flows  from  the  Exhaust  ob¬ 
ject  to  the  Airframe  system  and  the  Instrumentation  system. ^^A  double-headed  arrow 
represents  two  single-headed  arrows,  one  pointing  in  each  direction.  The  arrows  are  always 
labeled  with  the  state  information  that  is  passed  between  the  objects.  The  label  nearest  the 
tail  of  an  arrow  names  the  data  flowing  toward  the  head  of  the  arrow. 

On  the  Engine  object  diagram,  the  Engine  S3rstem  is  the  area  within  the  large,  round- 
cornered  rectangle  (roundtangle).  The  roundtangles  external  to  the  Engine  system  represent 
other  systems  in  the  aircraft,  e.g..  Electrical  system  and  Fuel  system,  or  in  the  aircraft’s 
environment,  e.g.,  the  Environment  S5rstem.  A  system  is  composed  of  its  objects  and  the 
connections  between  the  objects.  These  connections  are  called  system-level  connections. 
Thus,  the  Engine  S3rstem  is  made  up  of  the  engine  objects  and  the  connections  between  them 
inside  the  roundtangle.  An  adrcrafl  simulator  for  a  multi-engine  aircraft  would  have  multi¬ 
ple  engine  systems.  Each  would  be  handled  identically  internally  but  would  have  different 
connections  to  the  outside  world. 

A  system  provides  two  abstractions.  First,  a  S3rstem  logically  groups  a  set  of  objects  and  their 
connections.  Second,  a  system  provides  an  update  abstraction  to  update  the  objects  as  a  unit 
in  order  to  maintain  system  state  consistency.  The  system  performs  the  update  by  gating, 
i.e.,  processing,  all  of  its  system-level  connections. 

The  final  icon  on  the  Engine  object  diagram  is  the  executive,  represented  by  the  heavy,  gray 
outline.  An  executive  groups  a  community  of  systems  and  coordinates  time  for  the  commu¬ 
nity,  i.e.,  provides  an  ordered  update  of  all  the  systems.  The  connections  between  systems 
are  executive-level  connections.  An  ordered  update  of  a  system  consists  of  two  steps: 


actuality,  all  connections  are  between  objects.  So,  more  correctly,  the  moc^  number  flows  from  some  object  in 
the  Airframe  system  to  the  Diffuaer  object  in  the  Engine  system.  This  point  will  be  elaborated  in  later  sections  of 
this  report. 
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•  gating  the  executive-level  connections  and 

•  calling  the  system  to  perform  its  update. 

The  object  diagram  thus  depicts  natural,  real-world  entities,  such  as  objects  and  systems, 
and  entities  that  originate  from  the  commitment  to  run  the  simulator  on  a  computer,  i.e,, 
connections  which  move  data  and  executives  which  control  time  and  allocate  resources,  such 
as  the  CPU.  Each  of  the  abstractions — objects,  connections,  systems,  and  executives — will  be 
discussed  in  more  detail  in  the  rest  of  this  chapter. 


4.3.  Object  Abstraction 

This  section  describes  an  object  abstraction  assuming  the  objects  are  identified.  The  engine 
diagram  in  Figxire  4-2  will  serve  as  an  example. 

Objects  correspond  to  real  world  entities.  Objects  generalize  behavior,  i.e.,  they  know  noth¬ 
ing  about  their  environment  and  they  are  identical  in  each  of  the  engines  in  a  multi-engine 
system.  They  only  differ  in  how  they  are  connected  to  their  environment.  The  objects, 
however,  have  no  knowledge  of  these  connections.^^ 

A  snapshot  of  the  latest  external  effects  is  retained  in  the  objects.  The  outputs  (also  called 
the  state  of  the  object),  which  are  readable  at  any  time,  are  always  consistent  with  the  latest 
snapshot.  The  function  of  the  objects  is  to  map  from  the  inputs  to  the  outputs. 

4.3.1.  Object  Managers 

Each  object  is  represented  by  an  object  manager.  There  is  a  single  object  manager  for  all 
instances  of  the  object. Referring  to  the  Engine  object  diagraun.  Figure  4-2,  there  will  be  an 
object  manager  for  each  of  the  objects  in  an  engine; 

•  Diffuser 

•  Rotorl 

•  Fan  Duct 

•  Rotor2 

•  Burner 

•  Bleed  Valve 

•  Exhaust 

•  EIngine  Casing. 

The  object  manager  defines  the  attributes  of  the  object.  The  attributes  are  invariant  charac¬ 
teristics  defined  at  elaboration,  e.g.,  an  ampere  rating  of  a  circuit  breaker. 


^®ConnectionB  are  described  in  Section  4.4. 

^^The  term  manager  is  used  because  all  access  to  each  object  is  administered  through  the  interface  defined  by  the 
object  manager. 
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The  object  manager  defines  the  operational  state  of  the  object.  The  operational  state  refers  to 
those  characteristics  which  may  change  with  time,  e.g.,  the  fnctional  state  of  a  rotor,  mal¬ 
functions,  or  aging  effects  on  various  components. 

The  object  manager  allows  the  object’s  environmental  effects  to  be  placed  on  the  object.  The 
environmental  effects  are  external  object  states  which  are  required  by  the  object  to  deter¬ 
mine  its  state.  The  environmental  effects  are  placed  on  an  object  by  connecting  procedures. 
The  procedures  defined  for  these  operations  are  described  in  Section  4.3.3. 

The  object  manager  implements  the  math  model  for  the  object.  The  math  model  is  imple¬ 
mentation  dependent.  The  math  model  maps  the  object’s  inputs  to  its  outputs. 

The  object  manager  produces  the  outputs  available  firom  the  object.  The  outputs  are  gener¬ 
ated  by  the  math  model,  using  the  environmental  effects  placed  on  the  object  and  any  addi¬ 
tional  constraints  imposed  by  the  attributes  and  the  operational  state  of  the  object.  The 
math  model  may  be  invoked  when  environmental  effects  are  placed  on  the  object  or  when 
outputs  are  read  firom  the  object.  This  is  an  implementation  level  decision  left  to  the  system 
designer;  it  is  not  defined  by  the  paradigm. 

The  object  manager  defines  an  interface  to  the  operations  available  on  an  object.  The  opera¬ 
tions  aDow  the  placing  of  environmental  effects,  updating  the  operational  state,  and  reading 
the  outputs  of  the  object. 

The  actual  instances  of  the  object  are  stored  in  object  aggregates  which  are  discussed  in 
Section  4.5.1.  An  aggregate  allows  named  access  to  the  objects;  no  procedure  call  is  required 
to  retrieve  the  object. 

Finally,  the  object  manager  is  independent  of  the  rest  of  the  system.  The  only  compilation 
dependencies  are  on  global  types. 

4.3.2.  Object  Manager  Structure 

The  representation  of  the  object  in  an  object  manager  is  declared  as  a  private  type  in  the 
package  specification.^"^  Figure  4-3  is  a  partial  package  specification  containing  typical  type 
definitions  found  in  an  object  manager.^®  Use  of  a  private  type  allows  external  access  to  the 
object,  through  the  oi>erations  provided,  while  hiding  the  details  of  the  object’s  implemen¬ 
tation.  In  addition,  the  package  specification  must  define  all  the  types  used  to  describe  the 
object’s  attributes,  the  operational  state,  and  the  placeholders  for  environmental  effects. 


'^For  example,  "type  Burner  is  private”  in  Figure  4-3. 

^®Package  Standard_Engine«ring_Typea,  withed  at  the  beginning  of  Package  Bumer.ObjectJVIanager  in 
Figure  4-3,  contains  global  definitions  for  typical  simulator  types.  The  package  is  shown  in  Appendix  Section  C.2. 
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with  Standard_Engineering_Types; 
package  Bumer_Object_Manager  is 

package  Set  renames  Standard_Engineering_Types; 
type  Burner  is  private  ; 

—  an  Burner  is  an  abstraction  of  a  Burner  within  an  Engine. 

type  Spark  is  (None,  Low,  High); 

—  burner  needs  only  to  know  relative  spark  size 

type  Puel_Flowis  (None,  Flowing); 

~  the  burner  needs  to  know  only  if  it  has  fuel  available 

function  New^Bumer  return  Burner, 

procedure  Give_Inlet_Air_To 

(A_Bumer  :  in  Burner; 

Given_Inlet_Pres5ure  :  in  Set. Pressure; 

Given_Inlet_Temperature  :  in  Set.Temperature; 

Given Jnlet_Air_Flow  :  in  Set.Air.Flow); 

procedure  Get_Di8charge_Air_From 
(A-Bumer :  in  Burner, 

Retuming_Discharge_Press\ire  :  out  Set. Pressure; 
Retuming_Discharge_Temperature  :  out  Set.  Temperature; 
Retuming_Discharge_Air_Flow  :  out  Set.Air_Flow); 

procedure  Give_Puel_Flow_To 

(A.Bumer  :  in  Burner, 

Given.Puel.Flow :  in  Puel.Flow); 

procedure  Give_Spark_To  (A_Bumer  :  in  Burner, 

Given_Spark :  in  Spark); 

pragma  Inline  (GiveJnlet_Air_To, 

Get^Discharge.Air.Prom, 

Give_Puel.Flow_To, 

Gi  ve_Spark_To ) 

private 

type  Bumer^Representation; 

—  incomplete  type,  defined  in  package  body 

type  Burner  is  access  Bumer.Representation; 

—  pointer  to  an  Burner  representation 

end  Bumer_Object_Manager; 


Figure  4-3:  Bumer_Object_Manager  Package  Specification 

the  Burner  Object  Manager  in  Figure  4-3,  type  definitions  for  Spark  and  Fuel_Flow 
are  provided.  In  the  private  part  of  the  package  specification,  the  object’s  private  type  is 


^^The  attributes  and  operational  state  variables  must  be  visible  to  the  system  aggregate  package  which  instan¬ 
tiates  the  object  and  to  the  system-level  and  executive-level  connections  packages  which  use  the  object’s  types  and 
operations.  See  Sections  4.4,  4.5,  4.5.1,  and  4.6  for  descriptions  of  connections,  systems,  aggregates,  and  executives, 
respectively. 
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declared  as  an  access  pointer  to  a  data  type  which  will  be  the  actual  representation  of  the 
object.  The  data  type  is  an  incomplete  type,  the  details  of  which  are  delayed  until  the  pack¬ 
age  body.^® 

The  objoct’r^  data  representation,  defined  in  the  package  body,  must  allow  for  storage  of  en¬ 
vironmental  effects  and  reading  of  the  object’s  outputs.  A  typical  implementation  is  a  record 
with  components  for  each  of  the  object’s  attributes,  operational  state  variables,  and 
placeholders  for  the  environmental  effects.  Each  attribute  component  must  have  a  default 
value  and  each  operational  state  variable  should  have  an  initial  state  value.  Figure  4-4 
contains  an  incomplete  package  body  for  the  Burner  object  manager.  The 
Burnerjlepresentation  is  a  record  with  fields  for  environmental  effects,  e.g.,  inlet  air  pres¬ 
sure,  temperature,  and  flow,  fuel,  and  spark  values.  The  record  also  has  fields  for  output 
values,  e.g.,  discharge  pressure,  temperature,  and  flow. 


package  body  Bumer_Object_Maiiager  U 

type  Bumer_Representation  i* 
record 

Inlet^^Air^Presaure  :  SetPressure  :=  0.0; 
Inlet^Temperature  :  Set,Temperature  :=  300; 
Iiilet_Air_Flow  :  Set.Air_Flow  :=  0.0; 
The_Spark  :  Spaik  High; 

The^Puel  :  PueLFlow  :=  Flowing; 

DiBcharge_Air_Pre88ure  :  SetPressure  :=  0.0; 
Discharge.Temperature  :  Set. Temperature  :=  300; 
Di8charge_Air_Flow  :  Set.Air_Flow  :=  0.0; 
end  record  ; 


—  Subprogram  bodies  go  here 
end  Bumer.Object^Manager; 


Figure  4-4:  Bumer_Object_Manager  Package  Body 

4.3.3.  Object  Manager  Operations 

There  are  three  types  of  operations  within  each  object  manager.  There  is  also  a  standard 
naming  convention  for  these  operations.  One  side  effect  of  the  naming  convention  is  that  all 
object  managers  begin  to  look  very  similar.  The  similarity  can  be  exploited  to  create  an 
object  manager  template,  see  Chapter  5,  which  can  be  used  to  generate  new  object  managers. 

The  first  type  of  operation  is  used  to  create  new  instances  of  the  object.  This  operation  is  a 
function,  named  New_<object>^^,  which  returns  an  instance  of  the  private  type,  <object>. 


^See  Appendix  Section  C.4  for  the  complete  Package  Specihcation  for  the  Burner  object.  Appendix  C  provides  an 
implementation  of  the  Engine  system  through  the  Ada  specifications. 

^^The  use  of  ”<...>"  within  subprogram  names,  type  names,  or  text  refers  to  a  general  case  of  the  item.  For 
example,  New_<object>,  is  the  general  form  representing  all  instances  of  the  New  function,  e.g.,  New_Bumer, 
N©w_Rotorl,New_Exhau«t,  etc.  See  Chapter  5  for  a  more  detailed  discussion  and  examples  of  the  use  of 
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For  example,  in  Figure  4-3,  the  function  provided  by  the  Burner  object  manager  is  called 
New_Bumer;  it  returns  an  instance  of  the  private  type,  Burner.  This  private  type  is  a 
pointer  to  a  new  instance  of  the  data  type  representing  the  object.^^  In  addition,  values  for 
attributes  or  operational  state  variables,  which  need  their  default  values  changed  or  their 
initial  values  defined,  may  be  set  by  the  New_<object>  function.  Typically,  this  function  is 
called  at  elaboration,  i.e.,  during  system  initialization.  The  return  value,  a  pointer  which  is 
the  "ID"  of  the  new  object,  is  stored  and  used  to  access  the  object  in  later  operations.  See 
Section  4.5.1  for  more  discussion  on  this  point. 

The  second  type  of  operation  is  used  to  write  external  effects,  i.e.,  environmental  effects  and 
operational  state  cheinges,  on  an  object.  The  naming  convention  for  this  operation  is 
Give_<extemal_effects>_To.  The  operation  takes  the  object  private  type  and  either  exter¬ 
nal  environment  values  or  new  operational  state  values  as  arguments.  In  Figure  4-3,  the 
procedure  Give_Iiilet_Air_To  is  an  example  of  this  type  of  operation. 

The  characteristics  of  the  Give_<extenial_effects>_To  procedure  are  as  follows: 

•  report  external  environmental  effects  to  the  object.  The  stored  values  of  the 
environmental  eflFects  will  be  used  the  next  time  the  object’s  outputs  are  cal¬ 
culated.  These  updates  are  typically  under  the  control  of  a  cyclic  executive  and 
are  placed  on  the  object  one  or  more  times  each  cycle. 

•  report  a  change  in  the  operational  state  to  the  object.  The  stored  values  of  the 
operational  state  variables  will  be  used  the  next  time  the  object’s  outputs  are 
calculated.  These  changes  are  typically  as5mchronous  events  triggered  by  the 
instructor  at  the  lOS. 

•  the  environmental  effects  and  operational  state  variables  are  "saved"  with  the 
object  in  the  private  data  structure. 

•  the  environmental  values  stored  with  the  object  are  consistent  with  the  external 
effects  at  all  times. 

Ideally,  the  math  model  isolates  the  individual  effects  of  the  environmental  effects.  Calcula¬ 
tion  of  the  object’s  outputs  can  be  postponed  until  the  object’s  internal  state  is  read. 

The  interfaces  defined  by  the  Give_<extemal_effect8>_To  operations  can  be  read  directly 
off  the  object  diagram.  Figure  4-2.  There  will  be  one  procedure  per  dataflow  arrow.  For 
example,  in  Figure  4-3,  procedure  Give_Inlet_Air_To,  for  the  Burner  object  manager, 
takes  the  pressure,  temperature,  and  air  flow  as  arguments. 

The  third  type  of  operation  is  used  to  read  an  object’s  outputs.  The  outputs  are  calculated  by 
the  math  model  using  the  environmental  effects  placed  on  the  object  and  any  additional 


^There  are  other  options  for  managing  storage  allocation  for  the  objects.  One  is  to  use  the  allocator  directly, 
within  the  S3mtem  aggregate  package,  rather  than  performing  the  function  call  to  Now_<object>.  But  then  the  type 
<object>_Representation  would  have  to  be  visible.  A  second  method  would  be  to  build  an  alternate  allocator 
\ising  statically  defined  <object>_Re presentations.  Then  each  time  gin  <object>  had  to  be  allocated,  one  of  the 
statically  defined  instances  would  be  assigned.  This  approach  has  merit  if  garbage  collection  is  an  issue.  We  are 
continuing  to  look  into  these  and  other  approaches. 
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constraints  imposed  by  the  attributes  and  the  operational  state  of  the  object.  The  naming 
convention  for  this  operation  is  Get_<object_output>_From.  The  operation  takes  the  ob¬ 
ject  private  type  as  an  argument  and  returns  the  object’s  outputs.  In  Figure  4-3,  the  proce¬ 
dure  Get_Dischai^e_Air_From  is  an  example  of  this  type  of  operation. 

The  characteristics  of  the  Get_<object_output>_From  operation  are  as  follows: 

•  the  response  reflects  the  current  state  of  the  object.  The  state  is  dependent  on 
the  environmental  effects  previously  placed  on  the  object,  the  object’s  attributes, 
and  the  object’s  operational  state.  The  outputs  are  read  from  the  private  data 
structure  or  calculated  from  the  values  stored  in  the  data  structure. 

•  the  output  state  of  the  object  is  consistent  with  the  external  environmental  ef¬ 
fects  at  all  times 

•  each  operation  is  specific  to  the  object  and  the  output  of  the  object  that  it  reports. 

This  operation  is  the  only  way  to  access  the  object’s  output. 

The  interfaces  defined  by  the  Get_<object_output>_From  operations  can  be  read  directly 
off  the  object  diagram.  Figure  4-2.  There  should  be  one  procedure  per  dataflow  arrow.  For 
example,  in  Fig^ure  4-3,  procedure  Get_Discharge_Air_From,  for  the  Burner  object  man¬ 
ager,  returns  the  pressure,  temperature,  and  air  flow. 

The  output  state  of  an  object,  determined  from  its  environmental  effects,  attributes,  and 
operational  state,  may  be  calculated  either  when  new  external  information  is  written  to  the 
object  (and  then  the  output  state  should  be  stored  with  the  object),  by  the 
Give_<extemal_effects>_To  procedure,  or  when  outputs  are  read  from  the  object,  by  the 
Gret_<object_output>_From  operation.  In  the  first  case,  each  time  an  external  effect  is 
deposited,  a  new  output  state  should  be  calculated  and  stored  so  that  the  correct  output  state 
can  be  returned  on  subsequent  read  operations.  Since  each  external  effect  is  independent  of 
all  others,  the  object’s  output  state  will  be  consistent  at  all  times.  In  the  second  case,  an 
object’s  output  state  is  not  stored,  but  calculated  each  time  the  outputs  are  read.  The  deci¬ 
sion  as  to  which  implementation  to  use  is  up  to  the  implementor  of  the  system.  That  level  of 
detail  is  not  specified  in  the  paradigm. 

4.3.4.  Advantages  of  the  Object  Abstraction 

The  object  abstraction  developed  here  is  the  second  of  two  meanings  of  object  orientation.^^ 
The  object  abstraction  includes: 

•  the  packaging  strategy  used,  i.e.,  private  t3rpes  and  local  data  stored  with  the 
object 

•  the  object  operations  which  are  intentionally  designed  without  side  effects 

•  the  objects  which  are  stand-alone  with  no  dependencies  on  other  entities  in  the 
solution 

Thus,  there  is  a  natural  progression  fi-om  real-world  entities  to  design  objects  and  from  de¬ 
sign  objects  to  a  consistent  software  representation. 


^The  first  was  the  correspondance  between  real-world  entities  and  design  objects  on  page  17. 
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The  implementation  of  objects  follows  the  standard  model  for  object-oriented  abstraction. 
The  object  managers  embody  the  state  of  objects,  and  changes  in  the  objects’  environment  are 
placed  on  the  objects  procedurally.  The  major  difference  is  the  removal  of  connections  from 
the  objects  (connections  are  described  in  Section  4.4).  This  decision  supports  separate  devel¬ 
opment  of  objects  since  there  is  no  dependency  on  any  modules  other  than  global  types.  In 
addition,  spaghetti  compilation  dependencies  are  prevented.  Finally,  reuse  is  supported, 
since  data-type  differences  between  objects  are  not  an  issue.^"^ 

Another  advantage  of  the  object  managers  is  to  focus  the  addition  of  details  in  one  place.  For 
example,  if  there  is  loss  of  efficiency  in  the  movement  of  air  through  the  Burner,  the  loss  can 
be  modeled  in  the  object  manager  for  the  Burner.  Also,  malfunctions  in  components  can  be 
simulated  in  the  objects.  The  introduction,  handling,  and  reporting  of  a  malfunction  should 
be  introduced  at  the  object  manager  level. 


4.4.  Connection  Abstraction 

In  the  real-world,  laws  of  nature  or  physics  govern  the  transfer  of  state  information  between 
objects.  For  example,  heat  provided  by  the  Burner  is  transferred  to  the  air  flowing  through 
it.  Futhermore,  the  laws  of  nature  function  continuously  on  a  single  "processor”  without 
regard  for  units  of  measurement  or  other  information. 

In  a  computer  system,  state  information  must  be  transferred  explicitly  among  objects  that 
are  updated  in  discrete  time  on  multiple  processors  and  must  be  transferred  with  some  type 
of  units. 

This  section  describes  connections,  the  mechanism  for  transferring  state  information  be¬ 
tween  objects.  Connections  do  not  correspond  to  real-world  entities  such  as  wires  or  pipes. 
Connections  simply  model  the  proximity  of  one  object  to  another  in  the  real-world. 

4.4.1.  Overview  of  Connections 

The  connections  in  Figure  4-2  are  represented  by  arrows.  An  arrow  points  in  the  direction  of 
data  flow.  A  double-headed  arrow  represents  dataflow  in  both  directions. 

Connections  also  provide  a  means  to  transfer  information  between  physical  objects  and  soft¬ 
ware  objects.  Buffers  can  exist  between  physical  objects  and  the  software  system.  The 
buffers  may  be,  for  example,  a  linkage  buffer  between  the  software  and  the  simulator 
hardware,  an  Instructor  Operator  Station  (lOS)  buffer  between  the  software  and  the  lOS 
station,  or  buffers  between  processors  in  a  multi-processor  configuration.  In  all  these  cases, 
the  connection  handles  the  transfer  of  environmental  effects  or  operational  state  information 
from  the  bxxffer  (the  representation  of  the  physical  object)  to  the  software  objects  and  the 
transfer  of  object  state  fi:*om  the  software  objects  to  the  buffer.  For  example,  software  lights 
in  the  electrical  system  can  be  turned  on  and  off  as  a  result  of  external  environmental  effects 


^One  of  the  roles  of  connections  is  to  convert  types  when  necessary,  see  Section  4.4. 


CMU/SEI-88-TR-30 


27 


or  operational  state  changes.  These  effects  must  be  transferred  to  the  simulator  cockpit  and 
affect  a  change  in  the  physical  lights.  Lights  can  also  be  turned  on  and  off  in  the  simulator 
cockpit  by  the  students.  These  effects  must  be  transferred  to  the  software  and  change  the 
operational  state  of  the  software  lights.  The  linkage  buffer  between  the  cockpit  and  the 
software  is  used  and  connections  handle  the  information  flow. 

Finally,  the  updating  of  a  system  is  accomplished  by  moving  information  along  connections  , 
i.e.,  gating  the  executive-level  and  system-level  connections  in  order. 

4.4.2«  Procedural  Abstraction 

The  connections  between  objects  are  captured  procedurally,  using  the  object  operations.  All 
connections  between  objects  within  systems  and  between  systems  are  modeled  this  way. 
These  operations,  defined  with  the  object,  allow  for  writing  information  to  the  object  and 
reading  information  from  the  object.  See  Section  4.3.3  for  more  discussion  on  the  object 
operations. 

Thus,  the  connecting  procedures  exist  outside  the  object  managers,  but  have  visibility  into 
the  object  managers. 

The  connecting  procedures  need  to  perform  three  steps: 

•  obtain  the  needed  information  directly  from  an  object 

•  convert  the  information  if  necessary 

•  put  the  information  directly  onto  another  object 

Each  step  is  discussed  in  more  detail  in  the  following  sections. 

4.4.2.I.  Get  Needed  Information 

The  initial  step  is  to  obtain  the  external  information  which  must  be  placed  on  an  object.  The 
provider  of  the  information  is  defined  within  an  object  diagram  at  the  tail  of  each  arrow,  as 
in  the  Engine  diagram.  Figure  4-2.  The  provider  will  be  either  an  object  in  an  external 
system,  e.g.,  the  Fuel  system  or  Ignition  system,  or  another  object  within  the  Engine  system. 

If  the  provider  is  from  an  external  system,  the  procedure  modeling  the  connection  must  have 
access  into  the  objects  of  each  system.  Thus  the  procedure  needs  to  exist  at  the  next  higher 
level  of  abstraction,  i.e.,  within  the  enclosing  executive.  These  connections  are  called 
executive-level  connections.  Within  the  executive  connection  procedure,  local  variables  may 
exist  to  allow  for  temporary  storage  of  the  information,  as  in  Figure  4-5.  The  ciirrent  value  of 
sparky  from  the  Ignition  object  manager,  is  obtained  with  a  call  to  G€t_Spark_From  and 
stored  in  the  local  variable  Some_Spark.  Thus,  although  the  paradigm  does  not  advocate 
careless  data-typing,  it  recognizes  that  perfect  type  matches  between  objects  will  not  always 
be  possible. 

If  the  provider  is  from  another  object  within  the  Engine  system,  then  the  enclosing  scope  of 
the  objects,  i.e.,  the  Engine  system  itself,  handles  the  connection.  These  connections  are 
•called  system-level  connections.  Figure  4-6  shows  the  connection  between  the  Diffuser  and 
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with  Standard_Engineering^Types; 
with  Engine_System_Aggregate; 
with  Ignition_System_Aggregate; 

with  Flight_System_Naines; 

with  Bumer_Object_Manager; 
with  Igmtion_Object_Manager, 

separate  (Flight_Executive_Connection_Manager) 

procedure  Proce8s_Extemal_Connections_To_Engine_System  is 

Intagrated_Drive_Energy :  Generator_Object_Manager.Energy; 

Some_Spark  :  Igmtion_Object_Manager.Spark; 

The_Bumer_Spark :  Bumer_Object_Manager .Spark; 

function  Spark_Conversion  (In_Spark  :  in  Igiution_Object_Manager.Spark) 
return  Bumer_Object_Manager.Spark  is 

begin 

case  In.Sparkis 
when  0  ..  2  => 

RETTURN  Bumer_Object_Maiiager.NonG; 
when  3  ..  9  => 

RETTURN  Bumer_Object_Manager.Low; 
when  10  ..  20  => 

RETTURN  Bumer_Object_Manager.High; 

end  case  ; 

end  Spark^Conversion; 

begin  —  Process_ExtemalJConneciionsjro_Engine_Syst€m 

for  An_Engine  in  Flight_SystGins_Names.Aircraft_Engines  loop 

Some_Spark  :=  Ignition_Object_Manager.Get_Spark_Prom 
(A_Ignition  =>  IgnitioA„SystGm_Aggregate.Igmtions 

(Engine6_To_Ignition_Map  (An_Engine))); 

The_Bumer_Spaik  :=  Spark_Conversion  (Some^Spark); 

Bumer_Object_M  anager.Give_Spark_To 

(A_Bumer  =>  Ekigine_Systom_Aggregate.Enginea 
(An_Engine).  The_Bumer , 

Given_Spark  =>  The_Biimer_Spark); 
end  loop ; 

end  Process_Extemai_Connectionfl_To_Engine_System; 


Figure  4-5:  Executive- Level  Connection  — 

Spark  Conversion  Routine 

the  Engine  Casing.  The  discharge  air  pressure,  temperature,  and  flow  are  obtained  from 
the  Diffuser  with  the  call  to  Get_Discharge_Air_From. 

4.4.2.2.  Convert  Information 

The  connecting  procedures  encapsulate  type  conversions.  Each  object  manager  maintains 
the  state  of  the  object  in  the  units  which  make  sense  to  that  object.  The  connecting  proce¬ 
dures  handle  the  type  conversions  which  are  necessary  between  the  object  managers. 
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with  Flight_System_Naiiies; 
with  Engme_System_Aggregate; 

with  Diffuser_Object_Manager; 
with  Engine_Casing_Object_Manager; 

package  body  Engine_System  is 

procedure  Update_Engine_S3rstem  is 

DiSu8or_Discharge_Pressure  :  Set.Pressure; 
Difhi8er_Di8charge_Temperature :  Set.Temperature; 
DifiHiser_Di8charge_Air_Flow  :  Set.Air_Flow; 

begin 

for  An_Engine  in  Flight_System_Naines.Aircraft_Engines  loop 

—  Model  the  connection  characterized  by  the  dependence  of  the 
—  Engine  Casing  on  the  Diffuser  for  Pneumatic  J^nergy. 

Difiuser_Object_Manager.Get_Discharge_Air_From 
(A_Difiuser  => 

Engine.System.Aggregate.Engines 

(Given_Engine_Naine).The_Diffuser, 
Retummg_Discharge_Pressure  => 
Difiuaer_Di8charge_Press\ire, 
Retuming_Di8charge_Temperature  => 
DiSuser^Discharge^Temperature, 
RetummgJ)i8charge_Air_Flow  => 
Di0u8er_Discharge_Air_Flow); 

Engine_Caamg_Object_Manager.Give_Air.Flow_To 
(A_Engine_Casmg  => 

Engine_S3r8tem_Aggregate  .Engines 

(Given^Engine_Name).The_Engine_Casing, 
Given^Air^Flow  =>  Difiuaer_Discharge_Air_Flow); 


end  loop  ; 

end  Update_Engine_S3r8tem; 
end  Engine_System; 


Figure  4-6:  System-Level  Connection 

In  Figure  4-5,^^  the  intermediate  value,  Some_Spark^  obtained  during  the  get  information 
step  above,  is  converted  to  the  local  variable  The_Burner_Spark  by  the  function 
Sparkle  on  version.  The^BurnerJSpark  is  defined  in  terms  of  the  spark  type  in  the 
Burner  object  manager. 


^*The  notation  used  in  Figure  4-5,  Engine_System^Aggregate.Englnes  (An_Engine).The^Burner,  is  part  of 
the  Engine  Aggregate  nomenclature  discussed  in  Section  4.5.1. 
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There  are  two  reasons  for  managing  type  conversions  within  the  connection  procedure. 
First,  the  object  managers  are  then  free  from  inter-object  type  dependencies.  The  object 
managers  become  stand-alone,  with  no  dependencies  other  than  on  global  data  types.  Thizs, 
the  object  managers  become  reusable  units.  Separate  development  of  the  object  managers  is 
also  supported.  The  second  reason  is  that  each  object  manager  has  a  different  need.  There  is 
no  reason  to  expect  that  the  Burner  object  manager  would  have  a  need  to  know  how  the 
Ignition  object  manager  maintains  the  spark  state.  For  example,  the  spark  from  the 
Ignition  object  manager  may  be  in  volts  while  the  Burner  maintains  the  value  as  an 
enumerated  type  (see  Figure  4-5). 

4.4.2.3.  Put  Converted  Information 

The  final  step  is  to  place  the  external  environmental  information  on  the  object  being  up¬ 
dated.  The  information  must  be  in  the  proper  type  to  match  the  dependent  object.  Once 
again,  a  picture,  like  that  in  Figure  4-2,  defines  the  destination  for  the  environmental  infor¬ 
mation.  The  procedures  Give_Spark_To,  in  Figure  4-5,  and  Give_Air_Flow_To,  in  Figure 
4-6,  are  examples  of  put  information  operations. 

4.4.3.  Advantages  of  Connections 

The  implementation  of  connections  in  connecting  procedures,  as  described  in  this  chapter, 
provides  a  consistent  and  natural  interface  to  the  objects. 

The  connections  insulate  the  objects  from  compilation  dependencies.  Objects  and  systems 
become  stand-alone.  Each  can  be  developed  independently.  Connecting  procedures  provide  a* 
firewall:  changes  in  implementation  to  objects  on  one  side  of  a  connection  do  not  affect  the 
implementation  of  objects  on  the  other  side. 

Connections  facilitate  independent  development  and  reuse.  In  particular,  connecting  proce¬ 
dures  provide  a  systematic  way  to  handle  typing  mismatches.  The  type  conversions  between 
objects  are  easily  managed  since  the  connecting  procedures  have  visibility  into  the  objects. 

Connecting  procedures  provide  a  consistent  means  of  updating  systems  and  objects.  Thus, 
connecting  procedures  provide  a  means  for  specifying  control  flow.  No  extraneous  concepts 
or  operations  are  required. 

Finally,  the  connecting  procedures  provide  a  locus  of  control  since  all  connections  at  an  ab¬ 
straction  level  are  handled  in  one  place. 


4.5.  System  Abstraction 

To  this  point  we  have  defined  objects  and  the  connections  between  them.  This  section  dis¬ 
cusses  a  method  for  grouping  the  objects  and  connections  together  into  a  logical  scope. 

A  system  is  an  aggregation  of  objects  (and  the  connections  between  the  objects)  with  a  com¬ 
mon  goal.  For  example,  the  objects  making  up  the  Engine  system  provide  thrust;  the  objects 
of  an  Electrical  system  provide  power.  The  system  (objects  and  connections)  is  updated  as  a 
single  entity. 
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Thus,  a  system  presents  two  abstractions.  The  first  is  the  aggregation  of  objects  accessible 
by  name  outside  the  system,  as  discussed  below.  The  second  is  the  set  of  connections  be¬ 
tween  the  objects  of  the  system;  these  system  level  connections  are  not  visible  to  the  execu¬ 
tive  lev'^sl.  The  set  of  connections  allows  for  an  ordered  update  of  the  system  as  a  unit. 

A  S3rstem  update  requires  nothing  more  than  gating  the  system  level  connections  as  de¬ 
scribed  in  Section  4.4.  Objects  outside  the  system  are  not  accessed  during  the  system  up¬ 
date.  The  update  is  initiated  by  a  procedure  call  from  the  executive  to  the  system. 


4.5.1.  System  Aggregates 

A  real-world  system  usually  consists  of  collections  of  objects.  An  aggregate  creates  and 
names  a  collection  of  objects.  An  aggregate  is  a  data  structure  containing  the  name  of  each 
object.  Objects  are  accessed  by  name.  A  procedure  call  is  not  required  to  obtain  a  "pointer" 
to  an  object  being  accessed. 

4.5.1.1.  Building  an  Aggregate 

As  was  described  in  Section  4.1,  an  engine  is  a  collection  of  objects,  including  the  diffuser, 
rotors,  a  burner,  and  so  forth.  Each  object  is  managed  by  its  own  object  manager.  An  engine 
record  can  be  constructed  as  a  grouping  of  these  objects  (see  the  Engine_Representation  in 
Figure  4-7). 


with  Biimer_Object_Manager; 
with  Bleed__Valve_Object_Manager; 
with  Difiuser_Object_Manager, 
with  Engino^Casingi^Object_Maiiager; 
with  Exhauat_Object_Maiiager; 
with  Fan^Duct_Object_MaiiAg©r; 
with  Rotorl_Object_Maiiager; 
with  RotoT2_Obj©ct_Manager; 

package  Engine.System.Aggregate  is 

type  Engme.Representation  is 
record 

—  Defines  an  engine  representation  as  consisting  of: 

The_Difiu8er  ;  Difiuser_Object_Manager.Diffuser; 

The_Rotorl  :  Rotorl_Object_Manager.Rotorl; 

The_Fan_Duct  :  FanJDuct_Object_Manager.Fan^Duct; 

The_Rotor2  :  Rotor2_Object_Manager.Rotor2; 

The_Bleed_Valve  :  Bleod_Valve^Object_Manager.Bleed__Valve; 
The_Burner  :  Bumer_Object_Manager.Biimer; 

The_Exhau8t  :  Exhaust_Object_Maiiager.Exhaust; 
The_Eiigine_Casing :  Engine_Casiiig_01::gect_Manager.Eiigine_Casing; 
end  record  ; 

end  Engine_System_Aggregate; 


Figure  4-7:  Engine  Representation  Example 

For  an  aircraft  as  a  whole  there  may  be  several  engines.  Using  a  constant  array,  an  aggre¬ 
gate  of  the  engines  can  be  created  which  stores  references  to  Engine_Representations,  one 
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for  each  engine  on  the  aircraft  (see  Figure  4-8).  The  constant  array,  Engines,  is  created  at 
elaboration  time.  Each  object  is  instantiated  by  a  call  to  the  function  New_<object>,  de¬ 
scribed  in  Section  4.3.3,  with  all  initial  conditions  set  by  default.  The  pointer  to  the  private 
type  returned  by  the  function  is  stored  with  the  name  of  the  object.  Thus,  reference  to  the 
object  can  be  done  by  name.  The  aggregate  data  structure  is  visible  so  no  procedure  call  is 
required  to  retrieve  an  object.  The  array  is  indexed  by  the  enumerated  engine  names 
Engiiie_l.^ngiiie_4.  The  engine  names  are  defined  in  a  global  type  package  that  defines 
all  the  system  names. 

The  constant  auray.  Engines,  is  defined  in  a  package  specification  to  allow  access  to  the 
Engine  system  by  an  external  system  which  with^  the  package  and  the  appropriate  object 
managers.  The  aggregate  and  object  managers  are  used  by  the  connecting  procedures,  dis- 
cxissed  in  Section  4.4.3,  to  reference  the  necessary  objects.  All  references  to  objects  are  done 
through  the  aggregates.  An  object  in  an  engine  is  referenced  as: 

Engmes(Engine_N  ame).The_<obj  ect> 

For  example,  the  Diffuser  of  Engine  1  is  referenced  as: 

Engmes(Eiigine_l  ).The_Diffuser 
and  the  Rotorl  of  Engine  3  is  referenced  as: 

Engines(Engin8_3  ).The_Rotorl 

The  code  fragment,  in  Figure  4-6,  shows  how  to  reference  an  Engine  object  using  the  Engine 
aggregate.  The  Discharge  Air  is  read  from  the  Diffuser  object  using  the  reference, 
Engine_System_Aggregate^ngme8  (Given_Eiigine_Name).The_Di£fuser  and  written 
to  the  Rotorl  object  using  the  reference,  Engine_System_Aggregate.Engines 
(Given_Engme_Naine).The_Rotor  1 . 

4.5.2.  Updating 

The  existence  of  systems  allows  the  processing  of  the  enclosed  objects  to  be  done  as  a  unit. 
The  process  of  updating  a  system  occurs  in  two  steps  (Figure  4-10): 

•  the  executive  processes  the  executive  level  connections,  see  Section  4.6.1) 

•  the  system  processes  the  S5^tem  level  connections 

The  operations  are  done  atomically  for  each  system.  This  means  that  when  it  is  time  to 
update  a  system,  all  work  necessary  to  complete  both  steps  of  the  update  is  finished  before 
the  process  is  begun  on  another  system. 

Processing  the  executive  level  connections  involves  gating  the  connecting  procedures,  as  de¬ 
scribed  in  Section  4.4.  The  external  effects,  i.e.,  effects  from  objects  external  to  the  system 
being  updated,  are  placed  on  the  S5^tem  objects  by  the  connecting  procedures  at  the  execu¬ 
tive  level. 

Once  all  the  external  effects  have  been  placed  on  the  system  objects,  then  the  system  level 
update  is  initiated  by  a  single  procedure  call,  Update_<sy8tem_naine>_System,  to  the  sys¬ 
tem. 
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with  Flight_System_Names; 
with  Bumer_Object_Manager; 
with  Bleed_Valve_Object_Manager; 
with  Diffuser_Object_Manager; 
with  Engine_Casiag_Object_Maxiager; 
with  Exhaust_Object_Maiiager; 
with  Fan_Diict_Object_Manager; 
with  Rotor l_Object_Manager, 
with  Rotor2_Object_Manager, 

package  Eiigine_System_Aggregate  is 

Engines  :  constant  array  (Flight_System_Names.Aircraft_Engines)  of 
Engine_Representation  := 

(Flight_System_Names.Engine_l  => 

(The^Difiiiser  =>  Diffiiser_Object_Manager.New_Diffuser, 
The_Rotorl  =>  Rotorl_Object_Manager.New_Rotorl, 
The_Fan_I>uct  =>  Fan_Duct_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_B\imer  =>  Bumer_Object_Manager.New_Bnmer, 
The^Exhaust  =>  Exhaust_Objoct_Manager.New_Exhaust, 
The_Engine_Casing  => 

Engine_Casing_Obj  ect_Manager.New_Engine_Casing), 

Flight_System_Namea.Engine_2  => 

(The^Difiiiaer  =>  Diff\iser_Object_Manager.New_DifiFu8or, 
The^Rotorl  =>  Rotor  l_Object_Manager^ew_Ro  tori, 

The^Fan^Diict  =>  Fan^Diict_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_0bj  ect_Manager.N  ew_Rotor2 , 

The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_Bumer  =>  Bumer_Object_Manager.New_B\imer, 
The_Exhaust  =  >  Exhanst^Obj  ect_Manager .N ew_Exhaust, 

The_Engine_Casing  => 

Engine_Caaing_Obj  ect_Manager.New_Engine_Casing), 

Flight_System_Names.Engine_3  => 

(The^Difinser  =>  Diff\iser_Object_Manager.New_Di£Fuser, 
The^Rotorl  =>  Rotor l_Object_Manager.New_Ro tori, 

The_Fan_I>act  =>  Fan^I>act_Olgect_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Obj  ect_Manager  e  w_Rotor2 , 

The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The^Bumer  =>  Bumer_Object_Manager.New_B\imer, 
The_Exhaiist  =>  Exhaust_Object_Manager.New_Exhaiist, 
The_Engine_Ca8ing  => 

Engine_Ca8ing_0bject_Manager.New_Engine_Casing), 

Flight_System_Names.Engine_4  => 

(The^Diffuser  =>  Difhiser_Object_Manager.New_Diffuser, 
The_Rotorl  =>  Rotor  l_Object_Manager.New_Rotorl, 
The_Fan_I>uct  =>  Fan_I>uct_Object_Manager.New_Fan^Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_Bumer  =>  Bumer_Object_Manager.New_^B\imer, 
The_Exhaust  =>  Exliaust_Object_ManagGr.New_Exha\ist, 
The_Engine_Casing  => 

Engine_Casing_0bject_M8uiagenNew_Engine_Casing)); 
end  Engine_System_Aggregate; 


Figure  4-8:  Engine  Aggregate  Example 

For  the  Engine  system  example,  the  external  connections  which  need  to  be  processed  are 
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those  from  systems  outside  the  Engine  system,  e.g.,  the  Fuel  system.  These  connections  are 
handled  at  the  executive  level.  Then  the  Engine  system  is  updated,  via  the  procedure 
Update_Engine_System  (Figure  4-10).  Performing  the  system  level  update  involves  proc¬ 
essing  the  connections  at  the  system  level.  The  connection  representing  the  dependency  of 
the  Rotorl  on  the  Engine  Casing  for  air  flow,  temperature,  and  pressure  is  shown  in 
Figure  4-6.  The  update  procedure  is  dependent  on  the  Engine  Aggregate  and  the  object 
managers. 

4.5.3.  Advantages  of  Systems 

The  implementation  of  systems,  as  described  in  this  chapter,  encapsulates  objects  and  con¬ 
nections  within  a  logical  scope.  A  system  needs  to  access  only  its  aggregated  objects,  the 
global  types  used  by  the  objects,  and  the  system  level  connections. 


This  separation  of  concerns  allows  for  several  things: 

•  reduction  of  the  impact  of  compilation  dependencies.  Systems  become  stand¬ 
alone.  Connecting  procedures  provide  a  firewall;  changes  in  implementation  to 
objects  in  a  system  on  one  side  of  a  connection  do  not  affect  the  implementation 
of  objects  in  another  system  on  the  other  side. 

•  separate  development  of  components  and  reuse.  Systems  are  self-contained. 
The  only  dependencies  are  on  global  t3^es  and  object  managers. 

•  potentially  easy  disbursement  within  a  multi-processor  environment  (more  on 
this  in  Section  6.1). 


4.6.  Executives 

An  executive  is  a  community  of  systems.  For  example,  the  Flight  Executive  contains  the 
Engine  system,  the  Electrical  system,  the  Fuel  system,  etc.  The  executive  controls  the  up¬ 
dating  of  all  the  systems  within  its  scope.  The  executive  handles  all  connections  between  its 
systems,  e.g.,  those  between  the  Engine  system  and  the  Fuel  system.  In  a  multi-processing 
environment,  in  this  model,  there  would  be  one  executive  level  per  processor.  The  executive 
would  have  access  to  buffers  for  communication  between  the  processors.  However,  the 
synchronization  among  the  processors  would  happen  outside  the  executive.^® 

4.6.1.  Implementation  of  an  Executive 

All  the  systems  within  the  executive’s  scope  are  known  to  the  executive,  as  are  all  the  objects 
in  those  systems.  The  executive  has  an  activity  table, indexed  by  system  names,  which 
defines  a  processing  order  for  those  systems.  An  implementation  for  use  within  a  cyclic 
executive  is  shown  in  Figure  4-9.  The  constant  array,  Its_Time_To_Do,  defines  the  frame 


^^For  this  domain,  in  order  to  meet  the  req\iired  deterministic  real-time  schedule,  Ada  tasking  is  not  a  viable 
solution.  In  our  view,  the  executive  functions  like  an  abstraction  of  a  CPU.  The  scheduler,  that  is  shown  in  Figure 
4-9,  replaces  the  Ada  tasking  model  at  run-time. 

^^The  nature  of  the  activity  table  is  not  a  concern  of  the  paradigm.  More  elegant  and  powerful  implementations 
are  possible. 
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with  Global_Types; 
with  Flight_Syst€m_Names; 

pcu^kage  body  Flight^Executive  is 

t3rpe  Active_In_Frame  is 

array  (Plight_System_Names.Name_Of_A_Flight_Syst€m)  of  Boolean; 

Its_Tiine_To_Do  :  constant  array  (Global_Types.Execution_Sequence)  of 
Active_In_Prame  ;= 

(Global_Type8.Frame_l_Mod\iles_Are_Executed  => 

(Flight_System_Names. Engine  =>  (True),  others  =>  (False)), 

Global^Types.  FraiQe_2_Modules_Are_Executed  => 
(Flight_System_Name8.Electrical  =>  (True),  others  =>  (False)), 

Global_Type8.FraiQe_3_Module8_Are_Executed  =>  (others  =>  (False)), 
Global_Type8.Frame_4_Modules_Are_Executed  =>  (others  =>  (False)), 

Global_Type8.Frame_5_Module8_Are_Exe<ruted  => 
(Flight_System_Names.Engine  =>  (True),  others  =>  (False)), 

Global_Type8.Frame_6_Modules_Are_Executed  =>  (others  =>  (False)), 
Global_Type8.Franie_7_Modules_Are_Executed  =>  (others  =>  (False)), 
Global_Types.Franie_8_Module8_Are_Executed  =>  (others  =>  (False))); 

end  Flight_Executive; 


Figure  4-9:  Executive  Activity  Table  Example 

in  which  each  system,  e.g.,  the  Engine  system  and  the  Electrical  system,  gets  processed.  The 
processing  is  actually  initiated  by  the  procedure  shown  in  Figure  4-10. 

The  updating  of  a  system  involves  writing  the  external  effects  on  the  system  and  then  telling 
the  system  to  update  itself.  These  operations  for  the  s3rstems  are  done  atomically.  For 
example,  in  Figure  4-10,  when  it  is  time  to  update  the  Engine  system,  a  call  is  made  to 
Flight_Executive_CormectionsJProcess_Engine_Coimections_To.  This  procedure  ac¬ 
cesses  the  Engine  objects  directly,  using  the  Engine  aggregate,  to  write  external  effects  onto 
the  Engine  objects.  Figure  4-5,  page  29,  shows  such  an  executive  level  connecting  procedure. 
The  fragment  reads  the  spark  from  the  Ignition  object  and  writes  the  spark  value  to  the 
Burner  object  in  the  Engine  system. 

Next,  the  procedure  Engine_System*Update_Engine_Sy8tem  is  called  to  process  the  sys¬ 
tem  level  connections.  When  this  operation  is  finished,  the  Engine  system  update  is  com¬ 
plete  and  the  system  is  consistent  with  all  its  external  effects. 

4.6.2.  Advantages  of  Executives 

The  implementation  of  executives  described  in  this  chapter  follows  the  same  model  of  connec¬ 
tions  used  at  the  system  level.  Additionally,  the  executive  has  scheduling  information  in  the 
form  of  an  activity  table  which  defines  an  order  for  processing  its  systems.  Using  the  activity 
table,  tuning  of  the  simulator  system  by  balancing  the  system  processing  across  the  frames 
of  the  cyclic  executive  is  simplified. 
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with  Flight_Executive_Conjiection_Manager; 
with  Flight_System_Naines; 

with  Engine^System; 
with  Electrical_System; 

package  body  Flight_Executive  im 

procedure  Up<iate_Flight_Executive  (iPrame  ;  in 

Global_T3rpes.Execution_Sequence)  ie 

begin 

for  A_System  in  Flight_Sy8tein_Names.Name_0f_A_Flight_System  loop 
if  Its_Tiine_To_Do  (Frame)  (A.System)  then 
caee  A_Systemie 

when  Flight_Sy8tem_Names.  Electrical  => 

Flight_Execu  tive_ConnGcti  on_Manager . 

Proce8S_Extemal_Connectiona_To_Electrical_System; 

Electrical_Sy8tem.Update_Electrical_System; 

when  Flight_System_Name8.Engine  => 
Flight_Executive_Connection_Manager. 

Proce88_Extemal_Connectiona_To_Engine_Sy8tem; 

Engine_Sy8tem.Up<iate_Engine_System; 

end  caee  ; 
end  if; 
end  loop ; 

end  Update_Flight_Executive; 
end  Flight_Executive; 


Figure  4-10:  Flight  Executive  Example 

Distributed  processing  can  be  handled  easily  by  partitioning  executives  across  the  available 
processors.  More  discussion  of  this  topic  is  in  Section  6.1. 


4.7.  Advantages  of  the  Architecture  of  the  Paradigm 

The  two  main  design  goals  for  the  paradigm  were  to  eliminate  unnecessarily  layered  objects 
and  to  simplify  dependencies  among  objects.  Both  goals  have  been  met. 

The  solution  does  not  contain  nested  objects  and  the  software  architecture  is  flat.  Connect¬ 
ing  procedures  provide  the  means  of  accessing  objects  for  transferring  state  information.  The 
connections  at  the  executive  level  can  access  all  objects,  in  the  systems  under  the  scope  of  the 
executive.  Objects  are  accessed  by  name  through  the  data  structures  which  aggregate  ob¬ 
jects  for  each  system.  A  procedure  call  is  not  required  to  obtain  a  "pointer”  to  the  object 
being  accessed.  We  assert  that  the  solution  is  natural.  A  spark  goes  to  a  burner,  not  to  an 
engine. 

The  abstraction  of  higher-level  objects,  such  as  engines,  is  captured  in  the  notion  of  a  system: 
a  set  of  objects  updated  as  an  entity.  The  benefits  of  nested  objects  are  retained,  i.e.,  high- 
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level  objects  can  be  updated  and  reused  as  a  single  entity.  This  abstraction  coupled  with  the 
approach  to  processing  connections  facilitates  multiprocessing.  Placing  a  set  of  systems  on  a 
separate  processor  requires  only  creating  an  executive  for  the  processor  and  making  minor 
changes  to  the  executive  level  connections  for  the  processor.  None  of  the  system  level  code 
changes. 

The  major  difference  between  this  paradigm  and  other  object-oriented  paradigms  is  the  use 
of  connecting  procedures  to  transfer  information.  Connecting  procedures  allow  objects  and 
systems  to  stand-alone.  Each  can  be  developed  independently.  Connecting  procedures  pro¬ 
vide  a  firewall:  changes  in  implementation  to  objects  on  one  side  of  a  connection  do  not  affect 
the  implementation  of  objects  on  the  other  side. 

Connecting  procedures  facilitate  both  independent  development  and  reuse.  In  particxilar, 
connecting  procedures  provide  a  systematic  way  to  handle  typing  mismatches.  It  is  desir- 
able»  but  not  always  possible,  for  two  connected  objects  to  use  the  same  types  to  commu¬ 
nicate. 

The  software  partitioning  of  connecting  procedures  simplifies  compilation  dependencies.  All 
access  to  objects  happens  through  connecting  procedures.  Thus,  it  is  only  the  procedures 
managing  connections  to  a  system  that  need  to  be  recompiled  if  an  object  manager  specifi¬ 
cation  changes.  Each  of  these  connecting  procedures  can  be  implemented  as  a  separate  proce¬ 
dure;  in  the  Ada  sense. 

Connecting  procedures  provide  a  consistent  means  of  updating  systems  and  objects.  Thus, 
connecting  procedures  provide  a  means  for  specifying  control  flow.  No  extraneous  concepts 
or  operations  are  required. 


Figure  4-11:  Object  Dependency  Example 


Figure  4-11  illustrates  some  of  the  flexibility  of  connections.^® 


Object  B  provides  object  A 


^Figure  4-11  ifl  the  same  as  Figure  2-1. 
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with  something,  i.e.,  a  connection  exists,  as  shown,  between  A  and  B.  Assume  that  A  and  B 
are  in  the  same  system. 

1.  If  B  needs,  or  is  coded  with,  a  different  type  of  sojnething  than  A,  then  the 
connection  procedure  converts  the  type. 

2.  If  B  moves  to  a  different  system,  then  the  ownership  of  the  connection  is 
changed  (from  system  level  to  executive  level). 

3.  If  B  moves  to  a  different  processor,  then  connect  the  tail  of  the  connection  arrow 
to  a  "buffer"  representing  the  other  processor  (See  Section  6.1  for  more 
information.) 

4.  If  B  needs  to  be  stubbed,  then  the  connecting  procedure  can  be  used  as  the 
stub.^^ 

The  paradigm  produces  software  that  is  easy  to  modify.  Typical  modifications  include  ad¬ 
justing  the  distribution  of  processing  among  the  frames  of  a  cyclic  executive,  adding  malfunc¬ 
tions,  adding  or  removing  objects,  and  modeling  wear  and  aging  of  components.  Examples  of 
some  of  the  potential  modifications  are: 

1.  Moving  the  update  of  a  system  to  a  different  frame  requires  a  change  only  in 
the  executive’s  schedule  table 

2.  Adjusting  the  air  flow,  for  one  of  the  systems  which  uses  air  flow,  can  be  done  in 
a  connecting  procedure  without  worrying  about  side-effects  in  the  other  systems 

3.  Adding  a  malfunction  to  an  engine  component,  the  Burner  for  example,  re¬ 
quires  only  the  following: 

a.  making  the  malfunction  selectable  at  the  Instructor  Operator  Station 
(lOS) 

b.  adding  a  connection  from  the  lOS  buffer  to  the  Burner 

c.  changing  the  model  of  the  Burner. 

4.  Adding  a  third  compressor  stage  to  the  engine  will  not  disturb  the  major  math 
models  of  the  engine.  It  requires  only  creating  the  object  in  software  and  add¬ 
ing  connections  to  the  object  from  the  Engine  Casing  object 

5.  Modeling  wear  on  a  Rotor  bearing  requires  adding  the  interface 
Time_Has_Pas8ed  (Amount:  Time)  to  the  object,  making  a  small  change  to 
the  private  type,  and  reducing  the  efficiency  of  the  Rotor  in  proportion  to  its 
time  in  service 

6.  Adding  a  system  to  an  executive  requires  creating  the  system,  its  connection 
and  aggregate  packages,  and  the  objects  necessary  to  describe  the  system.  The 
system’s  objects  need  to  be  accessible  by  the  executive’s  connection  package,  see 
Figure  3-5,  and  the  sj^tem  itself  needs  to  be  included  in  the  schedule  table  and 
update  procedure  of  the  executive.  The  software  architecture  tends  to  grow  out 
(or  flat)  not  down. 


^This  technique  is  used  consistently  throughout  the  Engine  code  in  Appendix  C.  The  examples  used  in  this 
chapter,  for  example  Figure  4-5  which  shows  a  connection  to  the  Ignition  object  manager,  were  constructed  for 
illustrative  purposes  only. 
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5.  Development  Process 


5.1.  Role  of  the  Paradigm 

The  development  of  systems  using  the  paradigm  is  a  design  activity.  The  paradigm  molds 
the  designer’s  analysis  of  the  requirements.  The  paradigm  accommodates  objects  and  con¬ 
nections.  The  result  of  the  analysis  of  the  requirements  is  a  set  of  real-world  objects  and 
connections  grouped  into  systems.  Once  this  choice  is  made,  the  paradigm  dictates  the  im¬ 
plementation. 

The  paradigm  can  be  viewed  as  a  means  of  consistently  specifying  objects,  connections,  sys¬ 
tems,  and  executives.  The  result  is  a  consistent  implementation.  Maintainers  do  not  need  to 
learn  the  architecture  of  each  system.  If  the  paradigm  is  followed,  all  systems  will  look  the 
same. 

During  acquisition,  the  architecture  of  each  system  does  not  need  to  be  evaluated.  The 
quality  of  the  architecture  that  follows  from  the  paradigm  needs  to  be  evaluated  only  once. 
Design  reviews  can  focus  on  the  anal3^is  of  requirements,  the  choice  of  objects  and  connec¬ 
tions,  and  system  groupings. 


5.2.  Templates  and  Reuse 

The  object  diagram.  Figure  4-2,  used  four  icons  to  describe  the  Engine  system.  Objects  are 
represented  by  rectangles,  connections  between  objects  by  arrowed  Unes,  roimdtangles  are 
systems,  and  executives  are  defined  by  an  irregular  shape  outlined  in  gray.  Software  sys¬ 
tems  of  flight  simulators  can  be  defined  in  terms  of  these  four  icons. 

The  software  architecture.  Figure  3-5,  can  be  derived  mechanically  from  the  object  diagram. 
Each  of  the  four  icons  is  associated  with  its  own  set  of  one  or  more  software  package 
templates.  Relationships  among  the  software  package  templates  are  homomorphic  to  the 
relationships  among  the  icons  of  the  object  diagram.^® 


^Homomorphic  means  “"the  same  in  meaning  yet  shown  with  a  different  structure”. 


CMU/SEI-88-TR-30 


41 


with  Standard_Engineeriiig_Types; 
package  <Object>^Object_Manager  is 

package  Set  renames  Standard_£iigineering_Types; 
type  <Object>  is  private  ; 
type  <Attribute_2>  is  ??; 
type  <Attribute_l>  is  ??; 


function  New_<Object>  return  <Object>; 

~l  Demcription: 

—  I  This  function  returns  a  pointer  to  a  new  <object>  object 

—  I  representation  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


—  1  Parameter  Description: 

—  I  return  <object>  which  is  an  access  to  a  <object>  object. 

..  I  ***************************************************************** 


procedure  Give_<State_l>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_l>  :  in  Set.<Type_l>; 
Given_<Input>_<Type_2>  :  in  Set.<Type_2>; 
Given_<Input>_<Type_3>  :  in  Set<Type_3>); 

***************************************************************** 

Description: 

Initiates  a  change  in  the  specified  <object>  objects 
state  given  the  <input>_<type_l>,  <input>_<type 
and  the  <input>_<type_3>. 


—  1  Parameter  Description: 

—  t  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

—  I  Given_<input>_<type_l>  is  the  <input>  <type_l>,  in  ?? units 

—  I  Givenjcinput>_<typeJi>  is  the  <input>  <typ€^2>,  in  ?? units 

—  I  Given _<input>_<type_3>  is  the  <input>  air  flow,  in  units 


pragma  Inline  (Give_<State_l>_To); 

private 

type  <Object>.Repre8entation; 

—  incomplete  type,  defined  in  package  body 

type  <Object>  is  access  <Object>_Representation; 

—  pointer  to  an  <object>  representation 

end  <Object>_Object_Manager; 


Figure  5-1:  Object  Manager  Template  Example 

The  templates  contain  the  general  features  of  the  component,  with  place-holders  for  the  spe¬ 
cific  features.  Appendix  B  contains  a  complete  object  template.  The  template  uses  the  nota¬ 
tion  <object>  as  a  place-holder  for  the  name  of  the  object.  The  notation  <attribute_x>  is 
used  for  expression  of  operational  state  variables  and  attributes.  The  object  operations  are 
expressed  in  similar  terms  (See  Figure  5-1). 

The  templates  are  not  intended  to  contain  all  the  necessary  details  for  generating  a  complete 
version  of  the  code.  They  are  intended  as  a  starting  point.  The  framework  for  each  object 
manager,  system  update  package,  connection  package,  and  system  aggregate  is  similar.  The 
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details  are  different.  Package  bodies  and  subprogram  bodies  are  provided  within  the 
templates.  The  implementor  provides  details  within  a  template’s  framework.  The  resulting 
components  will  have  a  similar  look  and  structure.  This  will  aid  readability,  understanding, 
and  maintenance. 

5.2.1.  Diagram  Parsers 

Several  commercial  tools  have  the  capability  of  parsing  diagrams  and  generating  code 
templates  to  varying  levels  of  detail.  The  detail  is  limited  by  the  diagram  notation. 

The  object  diagram,  Figure  4-2,  is  typical  of  a  diagram  for  which  a  parser  could  be  written. 
The  parser  could  generate  the  templates  discussed  earlier.  We  view  this  as  a  natural  exten¬ 
sion  of  the  paradigm  toward  a  more  automated  solution. 


5.3.  Enhancements  to  Object  Diagrams 

The  notation  used  on  the  object  diagram.  Figure  4-2,  reflects  the  dependencies  between  ob¬ 
jects  and  state  information.  It  defines  the  connections  necessary  to  construct  the  system. 

Several  extensions  to  the  diagram  notation  can  be  envisaged.  One  would  be  to  delineate  the 
processing  order  of  the  connections.  The  Engine  Casing  is  the  object  through  which  the  air 
flows  as  the  air  passes  through  the  engine.  Each  of  the  other  objects  interacts  with  the  air  as 
it  flows  through  the  Engine  Casing.  Nothing  on  the  diagram  denotes  the  order  of  connec¬ 
tion  processing.  There  may,  however,  be  a  specific  order  necessary  to  insure  a  consistent 
state  of  the  Engine  system. 

Another  extension  would  be  to  add  pointers  to  algorithms.  The  algorithms,  expressed  in 
pseudocode,  could  be  inserted  in  package  bodies  by  the  diagram  parser. 


CMU/SEI.88-TR-30 


43 


44 


CMU/SEI.88-TR-30 


6.  Open  Issues 


6.1.  Distributed  Processing 

One  of  the  design  goals  of  the  paradigm  was  to  facilitate  spreading  the  work  load  over  multi¬ 
ple  processors.  The  description  that  follows  encompasses  our  theories  on  what  would  be 
required  to  distribute  the  processing  over  several  processors.  We  have  not  implemented  or 
tested  any  of  these  ideas. 


The  paradigm  begins  with  the  notion  of  an  executive.  An  executive  controls  the  update  of  a 
set  of  systems  compiled  together  and  thus  running  on  a  single  processor.  The  paradigm 
assumes  that  there  will  be  more  than  one  set  of  systems  and  that  multiprocessing  will  be 
involved. _ 


Integrated_Drive_Energy  := 

Grenerator_Obj  ect_Manager.  Gret_Energy_Proiii 
(A_G«nerator  =>  Ac_Power_Aggregate.Integrated_Drive_G€nerators 
(Engines_ToJdg_Map  (An_Engine))); 

Rotor2_Obj  ect_Manager.  Give^Torque^To 
(A_Rotor2  =>  Engine_System_Aggregate  .Engines 
(An_Engine).  The_Rotor2, 

Given_Torque  =>  Standard_Engineering_Types.Torque 
(Integrated_Drive_Energy)); 


Figure  6-1:  Executive  Connection  Procedure  Example 


Integrated_Drive_Energy’  := 
Flight_Executive_Bufrer.Get_Energy_Prom 
(A_Buflfer_Location  =>  Flight_B\iffer.Idg<An_Engine); 

Rotor2_Obj  ect_M  anager.Give_Torque_To 
(A_Rotor2  =>  Engine_Sy8tem_Aggregate.Engines 
( An_Engine),  The_Rotor2 , 

Given_Torque  =>  Standard_Engineering;^Types.Torque 
(Integrated_Drive_Energy)); 


Figure  6-2:  Communicating  with  a  Data  Transfer  Buffer 
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The  abstraction  of  higher-level  objects,  such  as  engines,  into  systems  allows  a  set  of  objects  to 
be  updated  as  an  entity.  This  abstraction  coupled  with  the  paradigm’s  approach  to  proc¬ 
essing  connections  facilitates  multiprocessing.  Placing  a  set  of  systems  on  a  separate  proces¬ 
sor  requires  only  creating  an  executive  for  the  processor  and  making  minor  changes  to  the 
executive-level  connections  to  the  system.^^  None  of  the  system-level  code  changes.^^ 

Communication  between  executives  is  handled  by  an  abstraction  called  a  buffer,  A  buffer  is 
some  means  of  sharing  data  among  separately  compiled  software.^^  The  paradigm  makes  no 
assumption  about  how  the  operating  system  transfers  data  or  how  executives  on  separate 
processors  are  invoked.  For  example,  assume  that  the  Flight  Executive  has  been  split  so 
that  some  of  its  systems,  e.g.,  the  Electrical  system  and  the  Fuel  system,  are  on  a  processor 
separate  from  the  Engine  system.  The  executive  that  handles  the  Engine  system  needs  to 
communicate  with  a  buffer  to  get  the  environmental  effects  from  these  other  systems.  Figure 
6-1  shows  how  connections  between  objects  are  typically  handled.  Figure  6-2  shows  how 
communication  between  the  executive’s  connecting  procedure  and  a  buffer  can  be  imple¬ 
mented.  The  fragments  read  the  torque  required  by  the  Integrated  Drive  Generator  ob¬ 
ject  manager  in  the  Electrical  system  from  the  buffer.  This  is  one  of  the  changes  required  to 
implement  a  system  on  distributed  processors. 

Another  required  change  would  be  to  load  the  buffer  with  the  states  of  objects  needed  by 
systems  on  the  other  processor.  All  outputs  required  by  systems  on  other  processors  must  be 
written  into  the  buffer.  This  step  would  take  place  after  the  update  of  the  system,  as  defined 
in  Section  4.5.2. 

One  can  imagine  a  development  environment  which  automatically  accommodates  the  distri¬ 
bution  of  systems  across  processors.  The  notations  for  the  object  diagram  could  be  extended 
to  indicate  which  systems  were  to  be  grouped  on  a  processor.  The  "address"  of  the  object 
read  by  a  connection  procedure  could  be  calculated  at  link  time:  the  choices  would  be  an 
object  or  a  bxiffer  surrogate. 


6.2.  Tuning 

The  construction  of  a  system  using  the  paradigm  results  in  a  product  which  is  easy  to  read, 
understand,  and  maintain.  The  performance  of  the  system,  however,  still  must  fit  into  the 
time  constraints  demanded  by  the  application.  The  implementation  described  in  the  para¬ 
digm  (and  embodied  in  the  templates)  is  intended  to  be  a  starting  point  for  a  usable  system. 


typical  minor  change  is  demonstrated  in  Figures  6-1  and  6-2. 

^^There  are  many  approaches  to  the  solution  of  this  problem.  We  do  not  intend  to  compare  or  delineate  all 
possible  solutions.  One  other  solution  would  be  to  have  the  generation  of  connection  dependencies  handled  by 
compiler  pragmas.  The  effects  would  be  the  same,  however.  Our  goal  was  to  minimize  perturbations  to  the 
connection  procedures. 

^^In  our  observations  of  flight  simulators,  a  buffer  is  a  record  data  structxire  used  in  the  communication  between 
processors. 
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We  fully  expect  that  adjustment  of  some  of  the  concepts  may  be  necessary.  For  example,  Ada 
allows  an  implementor  to  inline  certain  procedures  and  functions.  The  overhead  of  a  proce¬ 
dure  call  is  saved.  For  many  of  the  object  manager  operations,  which  are  only  a  few  lines 
long  and  tend  to  be  called  frequently  during  an  update.  Mining  may  provide  a  significant 
time  savings. 

Another  useful  technique  is  that  of  combining  effects.  For  example,  providing  multiple 
parameters  to  a  subprogram  instead  of  making  multiple,  individual  subprogram  calls.  The 
implementation  of  the  Engine  system,  described  in  Chapter  4,  demonstrates  this  technique. 
Figure  4-6  shows  an  exainple  with  three  parameters  in  the  subprogram  call 
Get_Di8charge_Air_From. 

A  second  method  for  combining  effects  is  to  group  like  objects  together.  For  example,  in  a 
simulator  electrical  system  the;re  are  hundreds  of  circuit  breakers.  Each  one  has  to  be  up¬ 
dated  with  respect  to  the  hardware  linkage  buffer  on  each  cycle.  Also,  at  each  level  several 
breakers  have  to  be  updated  through  their  connections  to  other  systems.  One  solution  is  to 
create  an  object  manager  that  handles  groups  of  identical  objects.  A  circuit  breaker  collec¬ 
tion  manager  would  contain  subprograms  for  dealing  with  groups  of  breakers  at  a  time. 
Thus,  a  single  subprogram  call  operating  on  a  group  of  objects  replaces  multiple  calls  each 
operating  on  individual  objects. 


6.3.  Reposition  and  IFlight  Freeze 

Flight  freeze  and  reposition  are  two  of  the  operating  modes  of  an  aircraft  simulator. 

In  the  flight  freeze  mode  the  simulator  software  state  is  frozen,  i.e.,  it  stops  changing  with 
time.  Communication  with  the  simulator  hardware  must  be  maintained.  Freeze  may  be 
initiated  by  the  instructor  at  any  time  during  a  training  exercise  when  communication  with 
students  is  necessary. 

The  reposition  mode  is  initiabsd  by  the  instructor  at  the  lOS  when  a  particular  training 
exercise  is  to  be  repeated.  Tlie  communication  between  the  simulator  software  and  the 
hardware  is  maintained,  and  new  values  for  flight  data  are  loaded  into  the  software.  After  a 
sufficient  waiting  period  to  allow  the  software  to  ramp  to  the  new  conditions,  the  simulator  is 
restarted. 

The  paradigm  considers  time  to  be  an  outside  effect  on  an  object.  Thus,  it  might  be  possible 
to  implement  flight  freezes  by  controlling  the  time  effects  on  objects.  Similarly,  a  reposition 
would  be  accomplished  by  using  reposition  connecting  procedures.  In  reposition  mode,  the 
executive  level  would  connect  £;5rstems  to  reposition  buffers.  A  connecting  procedure  would 
read  frem  the  buffer  instead  of  1;he  object  it  reads  from  during  normal  run  mode. 

We  have  not  implemented  or  t(5sted  these  ideas.  However,  we  are  convinced  that  the  para¬ 
digm  does  not  complicate  reposition  and  flight  freeze. 
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6.4.  System  Exports  and  System  Imports 


The  paradigm  makes  the  objects  of  a  system  visible  to  the  executive  and  to  other  systems. 
We  have  begun  to  study  the  merits  of  hiding  the  objects  behind  system-level  data  called 
expo^’^  ^md  import  areas. 

Currently,  the  paradigm  calls  for  a  connection  to  read  the  state  of  one  object  and  write  the 
state  of  another  object.  If  export  and  import  areas  are  used,  executive-level  connections 
would  move  data  from  the  export  areas  of  some  systems  to  the  import  areas  of  others. 

For  example,  the  Engine  system’s  import  area  would  contain  a  typed  variable  for  each  state 
of  its  objects  affected  by  other  systems.  Before  calling  for  an  update  of  the  Engine  system, 
the  executive  would  process  the  connections  to  the  Engine’s  import  area.  The  Engine  system 
would  have  system-level  connections  from  the  import  area  to  its  objects.  To  perform  an 
update,  the  Engine  system  would  gate  those  connections  in  conjimction  with  the  connections 
among  the  Engine  objects.  Upon  completion  of  the  update,  the  Engine  system  would  gate 
connections  from  its  objects  to  its  export  area.  Figure  6-3  shows  how  the  Engine  object 
diagram  would  appear  using  export  and  import  areas.  Figixre  6-4  shows  how  the  software 
architecture  would  appear. 

We  have  not  completed  analysis  of  this  approach.  The  only  apparent  benefit  is  subtle.  Re¬ 
member  that  an  object  can  update  its  state  when  given  a  new  environmental  effect  value. 
One  usually  assumes  that  moving  data  is  a  fast  operation.  However,  if  the  executive  writes 
directly  to  an  object,  which  updates  its  state,  then  the  movement  of  data  could  be  time  con¬ 
suming.  The  xise  of  export  and  import  areas  assumes  that  all  computations  will  occur  during 
the  update  of  the  system  instead  of  before  or  after  the  update  is  called  for  by  the  executive. 

The  use  of  export  and  import  areas  does  not  hide  information.  The  executive-level  connec¬ 
tions  will  terminate  either  at  objects  or  at  export  and  import  areas.  In  either  case  the  execu¬ 
tive  knows  about  the  same  number  of  reads  and  writes.  The  important  thing  is  that  even 
without  export  and  import  areas,  a  system  knows  nothing  about  any  other  systems. 


6.5.  Our  Executive’s  Control  of  Time 

A  system  expects  to  be  updated  at  regular  intervals.  It  also  expects  to  update  itself  with 
respect  to  a  consistent  set  of  external  effects.  Suppose  the  Engine  system  was  last  updated 
at  t20.  The  executive  is  preparing  to  update  the  Engine  at  t25.  The  Fuel  system  has  been 
updated  at  t25,  but  the  Electrical  system  was  last  updated  at  t20  and  will  not  be  updated 
again  imtil  t30. 


^“^However,  states  are  changed  and  read  only  through  connections.  Thus,  no  system  reads  from  or  writes  to  other 
systems. 

^^Compare  Figures  6*3  and  6*4  with  Figtires  4*2  and  3*5,  respectively. 
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Figure  6-Sl:  Alternative  Engine  Object  Diagram 
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Figure  6-4:  Alternative  Software  Architecture 


To  present  the  Engine  with  a  consistent  picture  of  its  world  at  t25,  the  executive  must  ex¬ 
trapolate  the  state  of  the  Electrical  S3rstem.  The  executive  must  keep  a  history  of  snapshots, 
in  this  case  one  from  tlO  and  one  finm  t20.  We  have  not  incorporated  this  in  the  paradigm, 
but  we  see  no  problem  in  doing  so. 


6.6.  Cyclicness 

We  have  not  studied  the  extent  to  which  the  executive  must  be  cyclic.  However,  we  see  no 
reason  to  force  updates  to  be  harmonic.  An  executive  is  nothing  more  than  a  dispatcher  that 
controls  time  and  access  to  a  central  resource,  the  CPU.  Algorithms  similar  to  the  rate 
monotonic  algorithms,  becoming  available  for  scheduling  tasks,  could  be  used  to  schedule  the 
updates  of  systems.  Since  the  algorithms  will  allow  tasks  to  run  at  discordant  periods,  the 
executive  would  not  have  to  be  cyclic  in  the  traditional  sense. 
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6.7.  Load  Balancing 


with  Flight_System_NarT''>s; 

with  Flight_Executive_Cormection3f2ii^g®r; 

with  Engine_System; 
with  Electrical^System; 

package  body  Flight_Executiye  is 

procedure  Up<iate_Flight_Executive  (Frame  :  in 

Global_Types.Execution^Sequence)  ia 

begin 

for  A«Systemin  Flight_System..Names.Name_Of_A_Flight_System  loop 
if  Its_Time_To_Do  (Frame)  (A.  System)  then 
case  A^System  is 

when  Flight_Sy8tem_Naiae8.  Electrical  => 

Fli  ght.Execu  ti  ve_Conne  c  tion_M  anager . 

Proce88_Extemal_Connections_To_Electrical_Sy8tem; 

Electrical_Sy8tem.Upda:e_Electrical_SyBtem; 

when  Flight_Sy8tem_Narae8.Engines_Fir8t_Part .. 

Flight  _Sy8tem_Names.Engine8_Foiirth_Part  => 
if  A.System  =  Flight_S^^8tem_Name8. 

Engine8_Pirst_Part  then 
Flight_E  xecutive_Connection_Manager. 

Proc  es8_Extemal_C  onnections^To^Engine^System; 

end  if ; 

Engine_System.UpdatB_Engine_System  (A_S3^tem); 

end  case  ; 
end  if; 
end  loop ; 

end  Update_Flight_Executive; 
end  Flight_Executive; 


Figure  6-5:  Executive  Example 

The  paradigm,  as  described,  requires  an  update  to  be  atomic.  This  means  that  when  the 
executive  regains  the  CPU  after  calling  a  sjrstem  update,  the  executive  expects  all  the  objects 
of  the  system  to  be  consistent  with  respect  to  the  external  world  presented  to  the  system  at 
the  start  of  the  update.  However,  it  may  not  be  possible  to  schedule  the  update  of  an  entire 
system  in  a  single  time  slice. 

The  paradigm  can  be  modified  to  accommodate  spreading  an  update  across  frames  of  a  cyclic 
executive.  For  example,  it  may  be  necessary  to  distribute  the  update  of  the  Engine  system 
equally  to  four  frames.  In  this  i2ase,  the  executive  would  process  all  connections  to  the  En¬ 
gine  system  before  calling  for  the  update  of  the  Engine  system.  The  executive  would  then 
call  the  Engine  update  procedure  four  times.  The  update  procedure  would  include  a 
parameter  indicating  the  cardinality  of  the  update:  first,  second,  third,  or  fourth.  The  system 
would  know  what  had  to  be  done  at  each  call.  Figures  6-5  and  6-6  show  how  the  executive- 
level  and  system-level  routines  ^\•ould  be  modified  to  accommodate  this  concept.^® 

^®Compare  Figures  6-5  and  6-6  to  Figures  4-10  and  4-6,  respectively. 
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with  Flight_S3rstem_Names; 
with  Engine_System_Aggregate; 

with  Diffuser_Object_Manager, 
with  Engine_Casmg_Object_Manager; 

package  body  Engine_System  is 

procedure  Update^Engine^System  ( 

A_System:  Flight_System_Naine8.Name_0f_A_Flight_System)i8 

Diffuser.Discharge^Pressure  :  Set. Pressure; 
Diffuser^Discharge^Temperature  :  Set. Tempera tiire; 
Diffu8er_Discharge_Air_Flow  :  Set.Air_Flow; 

begin 

case  A^System  is 

when  Flight_System_Names.Engines_First_Part  => 

—  Model  the  connection  characterized  by  the  dependence  of  the 
—  Engine  Casing  on  the  Diffuser  for  Pneumatic_Energy. 

Difi\iser_Obj  ect_Manager.Get_Discharge_Air_From 
(A^Diffuser  => 

EDgine_S3rstem_Aggregate.Engine6 

(Gi  ven_Engine_N  ame).The_Difiuser, 
RetumingJDischarge^Pressure  => 
Dif!uaer_DiBcharge_Pre8sure, 
Retuming_Di8charge_Temperature  => 
Dif!user_Di8charge_Temperature, 
Returmng_Di8charge_Air_Flow  => 
Difiuser_Di8charge_Air_Flow); 

Engine_Caalng_Obj  ect_Manager.  Give_Air_Flow_To 
(A_Ei3gine_Casing  => 

Eagine_Sy8tem_Aggregate.Engine8 

(Gi  ven_Engine_Name).  The_Engme_Casing, 
Given_Air_Flow  =>  Diffu8er_Discharge_Air_Flow); 
Proce88_Pir8t_Connection_Set; 

when  Flight_System_Names.Engines_Second_Part  =>  null ; 

—  do  some  other  Engine  connections  here 

when  Flight_System_Names.Engines_Third_Part  =>  null ; 

—  do  still  more  Engine  connections  here 

when  Flight_System_Names.Engines_Fourth_Part  =>  null ; 

—  do  the  rest  of  the  Engine  connections  here 

end  case  ; 

end  Update_Engine_System; 
end  Engine^System; 


Figure  6-6:  System  Example 

Note  that  the  executive  would  not  know  how  the  Engine  system  distributed  its  work.  The 
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executive  assumes  that  between  the  first  and  fourth  call  of  the  Engine  update  the  state  of 
the  Engine  system  is  undefined.  This  is  not  a  hardship;  the  executive  merely  broadcasts 
Engine  state,  i.e.,  gates  the  connections  from  the  Engine  system,  to  other  systems  before  the 
update  begins. 


6.8.  Generics 

Each  object  manager  in  the  pai'adigm  provides  an  allocator,  the  New_<object>  operation,  to 
create  instances  of  an  object.  For  example,  there  are  four  instances  of  the  Burner  object, 
one  for  each  engine. 

Reviewers  have  suggested  generics  as  an  alternative  approach  for  creating  multiple  in¬ 
stances  of  an  object.  Each  object  manager  could  be  a  generic  package  which  would  be  instan¬ 
tiated  once  for  each  object  needed.  The  generic  parameters  could  be  values  for  attributes  and 
the  operating  conditions  of  the  object.  Figxire  6-7  shows  a  generic  Burner  object  manager.^^ 
In  this  case,  there  are  no  genenc  parameters. 

There  are  two  immediate  advantages  to  such  an  approach.  First,  the  aggregate  data  struc¬ 
ture  would  not  be  needed.  The  instances  would  be  named  through  instantiation.  Figxire  6-8 
shows  how  the  generic  object  managers  would  be  instantiated  for  the  Engine  system.^® 

Second,  memory  for  the  objects  would  be  sdlocated  statically.  The  current  implementation 
causes  memory  to  be  allocated  on  a  heap,  even  though  the  number  of  instances  of  each  object 
is  constant. 

The  use  of  generics  to  create  S3r8tems  is  more  complicated.  Executive-level  connections  to 
systems  do  not  flow  between  the  same  instances  of  objects.  We  are  continuing  to  investigate 
the  use  of  generics  at  this  level. 


6.9.  System-Level  Objects 

In  the  paradigm,  the  Engine  system  is  the  sum  of  its  parts.  There  is  no  system-level.  Engine 
system  object  per  se.  The  Engine  system  has  no  state  other  than  the  states  of  the  objects 
which  make  up  the  Engine  syshjm. 

Some  systems  seem  to  require  a  system-level  object.  For  example,  the  case  of  an  IFF^^  box 
might  distribute  power  to  the  components  of  the  IFF  system  inside  the  case.  Under  the 
paradigm,  software  objects  woidd  be  created  to  model  the  selected  components.  The  case 
itself  also  might  be  modeled  with  a  software  object.  The  software  object  corresponding  to  the 


^^Compare  with  the  Burner  object  mauiager  in  Figure  4-3. 
^®Compare  with  the  Engine  Aggregabi  package  shown  in  Figure  4-8. 
^^Identify  Friend  or  Foe 
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with  Standard_Engineermg_Types; 
generic 

package  Burner_Object_Manager  is 

package  Set  renames  Standard_£ngineeriiig_Types; 
type  Burner  is  private  ; 

"  an  Burner  is  an  abstraction  of  a  Burner  within  an  Engine, 

type  Spark  is  (None,  Low,  High); 

—  burner  needs  only  to  know  relative  spark  size 

t3rpe  Puel^Flow  is  (None,  Flowing); 
the  burner  needs  to  know  only  if  it  has  fuel  available 

function  New_Bumer  return  Burner; 

procedure  Give_Inlet_Air_To 

(A^Bumer  :  in  Burner; 

GivenJnlet^Pressure  :  in  Set.  Pressure; 

Given^Inlet_Temperature  :  in  SeLTemperature; 
Given_Inlet_Air_Flow  :  in  Set.Air_Flow); 

procedure  (Jet^Discharge^^Air^Prom 
(A_Bumer :  in  Burner, 

Retuming_Di8charge_Pressure  :  out  Set, Pressure; 
Retuming.Discharg6_Temperature :  out  SetTemperature; 
Retuming_Di5charge_Air_Flow  :  out  Set,Air_Flow); 

procedure  Give_Puel_Flow_To 

(A_Bumer  :  in  Burner, 

Given_Puel_Flow :  in  Puel^Flow); 

procedure  Give_Spark_To  (A_Bumer  :  in  Burner, 

Given_Spark :  in  Spark); 

pragma  Inline  (GiveJnlet^Air^To, 

(}et_Di8charge_Air_Prom, 

Give_Puel_Flow_To, 

Give_Spaik_To) 

private 

type  Bumer^Representation; 

~  incomplete  type,  defined  in  package  body 

type  Burner  is  access  Bumer^Representation; 

—  pointer  to  an  Burner  representation 

end  Bumer_Object_Manager, 


Figure  6-7:  CJeneric  Object  Manager  Example 

case  would  be  an  object  at  the  same  level  as  the  objects  inside  the  case.  We  would  not  feel 
compelled  to  nest  component  software  inside  the  case  software. 

We  will  continue  to  investigate  the  need  for  objects  which  aggregate  system-level  informa¬ 
tion. 
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with  Bumer_Object_Manager; 

package  Engine_l_Buraer  U  new  Bumer_Object_Manager; 
with  Bumer_Object_Manager, 

package  Engine_2_Bumer  is  new  Bumer_Object_Manager; 
with  Bleed_Valve_Object_Manager; 

package  Engine_l_Bleed_Valve  is  new  Bleed_Valve_01:gect_Manager; 
with  Bleed_Valve_Object_Manager; 

package  Engine_2_Bleed_Valve  is  new  Bleed_Valve_Object_Manager; 
with  Difi\iser_Object_Manager; 

package  Engine_l_Difi\iaer  is  new  DifFuser_Object_Manager; 
with  Difi\isor_Object_Manager; 

package  Engine_2_Di£Puser  is  new  Diffaser_Object_Manager; 
with  Engme_Casmg_Object_Manage  r; 

package  Engine_l_Engine_Casing  ii(  new  Engine  Casing  Object  Manager: 
with  Engine_Casing_Object_Manage:r, 

package  Engine_2_Engme_Casing  iii  new  Engine_Casing_Object_Manager; 
with  Exha\ist_Object_Manager; 

package  Engine.l^Exhauflt  is  new  Ezhaiist^Object^Manager; 
with  Exhaiist_Object_Manager; 

package  Engme_2.Exhau8t  is  new  Ezha\ist_Object_Manager; 
with  Fan_Duct_0b3ect_Manager, 

package  Engine_l_Fan^Duct  is  nes^  Fan_Duct_Object_Manager, 
with  Fan_Duct_Object_Manager, 

package  Engine_2 _Fan^Duct  is  nesf  Fan_Duct_Object_Manager; 
with  Rotorl_Object_Manager, 

package  Engme_l_Rotorl  is  new  Ii^torl_Object_Manager; 
with  Rotorl_Object_Manager; 

package  Engine_2_Rotorl  is  new  Iictorl_Object_Manager; 
with  Rotor2_Object_Manager, 

package  Engine_l_Rotor2  is  new  Iictor2_Object_Manager; 
with  Rotor2_Object_Manager, 

package  Engine_2_Rotor2  is  new  Eotor2_Object_Manager; 


Figure  6-8:  Generic  Object  Instantiation  Example 
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7.  Electrical  System 


An  Electrical  system  in  an  aiicraft  provides  electrical  power  to  devices  in  other  systems: 
devices  such  as  fuel  pumps  and  valves  in  the  Fuel  system,  hydraulic  pumps  in  the  Hydraulic 
system,  and  air  conditioning  in  the  Environmental  Control  system.  The  systems  are  able  to 
function  only  if  power  is  available.  They,  in  turn,  put  their  load,  i.e.,  the  amount  of  current 
they  require,  back  onto  the  Electrical  system.  The  load  is  transferred  back  to  the  generators, 
along  the  Electrical  system  buses,  where  a  determination  of  possible  overloading  takes  place. 

A  subset  of  the  Electrical  system  has  been  completed  and  tested.  The  code  with  accompa¬ 
nying  documentation  is  available  on  request  from  the  authors.  The  code  illustrates  some 
concepts  not  illustrated  by  the  Engine  system  example. 


7.1.  Additional  Concepts 

The  Engine  system.  Appendix  C,  is  complete  through  the  package  specifications.  The  subset 
of  the  Electrical  system  is  fully  lunctional  and  has  been  thoroughly  tested. 

Several  performance  issues  arose  during  the  implementation.  There  are  several  hundred 
Circuit  Breakers  in  a  typical  ISlectrical  system.  Each  one  has  to  be  updated  with  respect  to 
the  hardware  linkage  buffer  on  each  cycle.  Also,  at  each  level  of  the  software  several 
breakers  have  to  updated  through  their  connections  to  other  systems.  The  subprogram  calls 
in  each  object  manager  were  inlined  in  order  to  reduce  the  overhead  during  update. 

Grouping  of  like  effects  is  also  performed.  Voltage  and  load  conversion  factor  (Icf)  are  up¬ 
dated  together.  In  addition,  volr^ge,  Icf,  and  current  are  grouped  in  a  data  structure  which  is 
used  during  all  read  operations  from  objects.  Both  steps  result  in  fewer  subprogram  calls. 

The  concept  of  updating  a  sysl^em  as  a  unit  means,  to  us,  that  all  aspects  of  the  system 
update  must  be  complete  in  the  execution  frame.  The  Electrical  system  subset  includes  a 
tie-bar,  an  electrical  bus  which  connects  several  other  buses.  In  order  to  insure  that  the 
update  is  complete  within  the  frame,  the  tie-bar  is  processed  repeatedly  in  the  frame.  The 
number  of  times  necessary  depends  on  the  number  of  other  connections  to  the  tie-bar. 

Other  issues  that  arose  during  the  complete  implementation  included  decisions  about  writ- 
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ing  effects  to  objects  and  reading  outputs  from  objects.  For  some  objects,  like  Circuit 
Breakers,  the  external  effects  are  written  and  outputs  are  calculated  during  a  read  opera¬ 
tion.  For  other  objects,  states  are  calculated  when  effects  change. 

The  Electrical  system  object  diagram.**  !  ^ok  like  circuit  diagrams.  Given  a  library  of  objects 
and  a  diagram  parser,  one  could  fully  automate  the  production  of  code  from  a  circuit 
diagram. 


58 


CMU/SEI-88-TR-30 


Appendix  A:  Software  Architecture  Notation 


The  notation  used  to  describe  the  software  architecture  is  a  modified  form  of  the  notation 
expounded  by  Grady  Booch  in  ]iis  book  on  software  engineering  with  Ada  [1]  and  his  book  on 
reusable  software  components  with  Ada  [2].  The  notation  used  is  true  to  the  intent  of 
Booch’s  notation.  The  variations  (i.e.,  extensions)  are: 

•  use  of  reduced  package,  subprogram  and  task  icons  inside  larger  icons  rather 
than  the  object  (or  blob)  icon 

•  use  of  object  dependenc]^  arrows  more  subtly,  to  distinguish  different  types  of 
dependencies 

•  internal  details  of  any  reusable  subsystem,  package,  subprog^m  or  task  are  not 
shown 

One  final  note  about  the  notation:  The  figures  need  not  show  all  the  fine-grained  detail  of  a 
package  or  subprogram.  When  the  code  of  a  package  (or  subprogram)  is  compared  to  a  figure 
associated  with  that  package  (or  subprogram)  there  may  be  nested  procedures  or  packages 
not  shown  on  a  particxilar  picture,  or  it  may  depend  on  a  package  not  explicitly  shown  in  the 
figure.  The  guidelines  for  thes(5  cases  are: 

•  utility  packages  or  services  are  not  shown  (this  includes  things  like  text_io,  reus¬ 
able  data  structure  packfiges,  math  libraries,  etc.) 

•  the  figures  are  meant  to  show  the  significant  details  at  a  particular  level,  not  all 
the  details 

•  the  definition  of  "a  significant  detail"  is  solely  at  the  discretion  of  the  designer 

Based  on  these  ideas,  Figures  A-1  thru  A-4  explain  the  meaning  of  each  of  the  icons  available 
using  this  notation. 
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Figure  A-1:  Object,  Subsystem  and  Dependency  Notation 

The  object  (or  blob)  icon,  shown  above  in  Figure  A-1  (a),  represents  an  identifiable  segment  of 
a  system,  about  which  we  have  no  implementation  information.  We  make  no  use  of  this  icon. 

The  subsystem  icon,  shown  above  in  Figure  A-1  (b),  represents  a  major  system  component 
that  has  a  clearly  definable  interface,  yet,  which  is  not  representable  as  a  single  Ada  pack¬ 
age.  We  currently  make  no  use  of  this  icon,  although  we  could. 

The  object  dependency  symbol,  shown  above  in  Figure  A-1  (c),  indicates  that  the  object  at  the 
origin  of  the  arrow  is  dependent  on  the  object  at  the  head  of  the  arrow.  The  origin  of  the 
arrow  indicates  where  the  dependency  occurs.  If  the  origin  is  in  the  white  area  of  an  icon 
(shown  in  subsequent  figures),  it  indicates  a  specification  dependency.  If  the  origin  is  in  the 
shaded  area,  it  indicates  a  body  dependency. 
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Figure  A-2:  Package  Notation 

The  package  specification  and  body  icon,  shown  above  in  Figure  A-2  (a),  represents  an  Ada 
package  specification,  the  wh' te  area,  with  an  associated  package  body,  the  shaded  area. 
This  icon  can  be  broken  apart  to  show  a  package  specification,  Figure  A-2  (b),  or  a  package 
body.  Figure  A-2  (c). 

Figures  A-2  (d)  and  (e)  are  variations  on  the  package  icon  which  show  greater  detail.  Figure 
A-2  (d)  is  used  to  represent  packages  which  have  nested  subpackages  within  the  body;  if  the 
small  package  icon  were  placed  within  the  specification,  it  would  indicate  visible  nested 
packages.  Similarly,  Figure  ^l-2  (e)  illustrates  the  notation  used  for  separate  subprograms 
within  the  body  of  a  package. 

Finally,  Figure  A-2  (f)  illustrates  the  icon  used  for  generic  packages.  Everything  discussed 
above  in  regard  to  regular  pacliages  can  also  be  applied  to  generic  packages. 
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Figxire  A-3:  Subprogram  Notation 

Much  of  what  was  discussed  previoxasly  in  regard  to  packages  also  applies  to  subprograms. 
The  subprogram  specification  and  body  icon,  shown  above  in  Figure  A-3  (a),  represents  an 
Ada  subprogram  specification,  the  white  area,  with  an  associated  subprogram  body,  the 
shaded  area.  This  icon  can  be  broken  apart  to  show  a  subprogram  body.  Figure  A-3  (b). 

Figures  A-3  (c)  and  (d)  are  variations  on  the  subprogram  icon  which  show  greater  detail. 
Figure  A-3  (c)  is  used  to  represent  subprograms  which  have  nested  subprograms  within  the 
body.  Similarly,  Figure  A-3  (d)  illustrates  the  notation  used  for  separate  subpackages  within 
the  body  of  a  subprogram. 

Finally,  Figure  A-3  (f)  illustrates  the  icon  used  for  generic  subprograms.  Everything  dis¬ 
cussed  above  in  regard  to  regulsu*  packages  can  also  be  applied  to  generic  subprograms. 
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Figure  A-4:  Task  Notation 

Again,  much  of  what  was  discussed  previously  in  regard  to  packages  and  subprograms,  ap¬ 
plies  to  tasks.  The  task  specification  and  body  icon,  shown  above  in  Figure  A-4  (a), 
represents  an  Ada  task  specification,  the  white  area,  with  an  associated  task  body,  the 
shaded  area.  This  icon  can  be  broken  apart  to  show  a  task  specification,  Figure  A-2  (b),  or  a 
task  body.  Figure  A-4  (c).  Although  they  are  not  shown,  nested  package  and  subprograms 
are  represented  in  exactly  the  same  manner  as  shown  in  Figure  A-2  for  packages  and  sub- 
progrsuns. 
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Appendix  B:  Object  Manager  Template 


—  The  following  are  instructions  regarding  the  use  of  this  template, 

~  We  realize  that  the  template  does  not  encompass  every  procedure 

—  which  might  be  needed^  however  with  alterations  to  the  existing 
~ procedures  one  can  easily  affect  the  neccessary  changes, 

^  Do  global  substitutes  on  the  following  : 

—  <object>  gets  the  name  of  the  object  being  created 

—  ie.  <object>  «>  Burner 

<input>  gets  the  general  prefix  for  indicating  that  a 

—  variable  is  input 

—  ie,  <input>  »>  Inlet 

~  <output>  gets  the  general  prefix  for  indicating  that  a 

—  variable  is  output 

~  ie,  <output>  *>  Discharge 

—  <ztate_n>  is  the  state  of  the  object  you  wish  to  modify 

—  Note  :  n  can  take  on  values  1  to  3  for  state_n, 

^  If  more  states  are  needed  the  user  should 

—  cut  the  existing  ones  to  create  more, 

—  ie.  <state_l>  »>  Air 

—  <typeji>  is  the  type  of  the  variable  within  a  state  which 

—  which  you  wish  to  modify. 

—  Note  :  n  can  take  on  values  1  to  9  with  1-5  corresponding 

—  to  state  ,  ...  The  user  should  remove  unwanted 
type, 

—  ie,  <type_l>  »>  Pressure 

—  <attribute_n>  are  the  attributes  of  an  object  you  wish  to  modify, 

—  Note  :  n  can  take  on  values  1  to  3 

—  ie,  <attribute_l>  =>  spark 

—  <typej%jLLnits>  and  <attribute_njunits>  are  the  units  corresponding  to 

to  the  types  and  attributes  used  within  the  object  manager. 

—  ie,  <iypeJijLLnits>  =>  pounds  per  square  inch 
ie,  <attributejijunits>  *>  joules 

—  do  a  search  now  for  all  instances  of  11  and  fill  in  the 

—  neccessary  information 

—  Finally  the  user  should  remove  all  unwanted  code  and  comments 


^  I  ********4i4i*4i4ntt**4i*4t****4t4t4t*4i*4t********************************4i4t* 

—  I  Module  Nctme: 

—  I  <object>_Object_Manager 
-I 


CMU/SEI-88-TR-30 


65 


Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  manages  objects  which  simulate  the 
Engine  <obJect>  for  the  C-141  simulator. 

This  management  entails  creation  of  <ohject>  object's 
updaiCt  maintenance  of  its  state,  and  state 
reporting  capabilities. 

Module  Description: 

The  <jobject>  object  manager  provides  a  means  to  create 
an  <object>  object  via  the  New_<object>  operation  and  returns 
an  identification  for  the  <object>,  which  is  to  be  used  when 
updating  f  accessing  the  <object>  object's  state  as  described  below, 

'The  <object>  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Give_<input>_<state_l>_To 

2)  Give_<input>_<state_2>JTo 

3)  Give_<input>_<stateJ>JTo 
4)  Give_<jattribute_l>_To 

5)  Give_<attribute Jl>_To 

6)  Give_<attribute_3>_To 

operations,  requiririg  the  following  external  state  information: 


1)  <input>^<type^l> 
<input>^<type_2> 

<input>jCiypeJ3> 

2)  <input>_<typeji> 
<input>^<typeJS> 

<input>_<typej6> 

3)  <input>jCtype_7> 
<input>^<type^8> 

<input>_<type_9> 

4)  <attribute_l> 

5)  <jaUributeJ2> 

6)  <jaUributeJ3> 


ctype^l  junits> 
<type_2junits> 
<typeJ3  jinits> 
<typejiju  nits> 
<type_5junit8> 
<typeJSjLLnUs> 
ctypeJIji  nits  > 
<typej3jinits> 
<type_9jLLnUs> 
<attribute_l_units> 
<attribute  JljunUs> 
cattribute  3  units> 


The  <object>  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get_<joutput>_<state_l> J'rom 

2)  Get_<output>_<state_2> _From 

3)  Get_<Dutput>_<state_3> J'rom 

operations,  yielding  the  following  internal  state  information: 
1)  <output>_<type_l>  <type_ljinits> 

<typejljinits> 

<typejjunits> 

<type_4junits> 

<type_5jLLnits  > 

<type_6_u  nits  > 

<typeJ!ji  nits  > 

<typejSjinits> 

<typ)ej9junits> 


<output>_<typeJ> 
<outp  ut>_<type_3> 

2)  <output>_<type_4> 
<output>_<typej5> 
<output>_<type_6> 

3)  <output>^<typeJ7> 
<output>_<typeJ3> 
<output>_<typeJ> 


References: 

none 

Design  Documents: 
none 

User's  Manual: 
none 

Testing  and  Validation: 
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—  I  Notes: 

—  I  none 


~  I  ModificcUion  History: 

—  I  24Aug87  cpp  Creation 
-I  13Jul88  hi  Modified 


DisirdbuHon  €tnd  Copyright  Notice: 


—  I  Distribution  unlimited 
~  I  No  warranty  is  implied 

—  I  Diaclctimer^ 

~  I  *Tkis  work  was  sponsored  by  the  Department  of  Defense,  ** 

^  I  *************************************************************************** 


with  Standard^Engineering^Types; 
package  <Object>_Object_Manager  is 


package  Set  renames  Standard_EngineeriBg.Types; 
type  <Object>  is  private  ; 

—  an  <object>  is  an  abstraction  of  a  <object>  within  an  Engine, 


type  <Attribute_l>  is  ??; 

—  the  <object>  needs  to  know  ?? 

type  <Attribute_2>  is  ??; 

~  the  <object>  needs  to  know  ?? 

type  <Attribute_3>  is  77; 

—  the  <object>  needs  to  know  ?? 


function  New_<Object>  return  <Object>; 

^ I  ***************************************************************** 

—  I  Description: 

—  I  This  function  returns  a  pointer  to  a  new  <object>  object 
- 1  representation.  This  pointer  will  be  used  to  identify 

~  I  the  object  for  state  update  and  state  reporting  purposes. 


Parameter  Description: 

return  <object>  which  is  an  access  to  a  <object>  object, 

***************************************************************** 


procedure  Give_<Input>_<State_l>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_l>  :  in  Set.<Type_l>; 
Given_<Input>_<Type_2>  :  in  Set»<Type_2>; 
Given_<Input>_<Type_3> :  in  Set<Type_3>); 

***************************************************************** 

Description: 

Initiates  a  change  in  the  specified  <object>  object*s 
state  given  the  <input>^<iype_l>,  <input>_<iype_2>, 
and  the  <input>_^ypeJ3>, 


~l  Parameter  Description: 

~  I  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

—  I  Given_<input>_<type_l>  is  the  <input>  <type_l>,  in  <type_l_units> 

—  I  Given_<input>_<iype is  the  <input>  <type_2>,  in  <iype_2_units> 

—  I  Given^<input>^<type^3>  is  the  <input>  <type_3>,  in  <iype_3junits> 

^ I  ***************************************************************** 
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procedure  Give_<Input>_<State_2>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_4>  :  in  Set.<Type_4>; 
Given_<Input>_<Type_5>  :  in  Set.<Type_5>; 
Given_<Input>_<Type_6>  :  in  Set.<Type_6>); 

Descri pHon: 

Initiates  a  change  in  the  specified  <object>  object* s 
state  given  the  <input>jctype_4>,  <input>^<type_5>, 
and  the  <input>_<type_6>. 

Parameter  Deecriptioru 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

Given _<input>_<type_4>  is  the  <input>  <type_4>,  in  <type_4junits> 
Given_<input>_<type^5>  is  the  <input>  <type_5>,  in  <type_5_units> 
Given_<input>_<type_6>  is  the  <input>  <typejB>,  in  <typejBjanits> 


procedure  Give_<Input>_<State_3>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_7>  :  in  Set<T3rpe_7>; 
Given_<Input>_<Type_8>  :  in  Set<Type_8>; 
Given_<Input>_<Ty^_9>  :  in  Set.<iype_9>); 

Deacription: 

Initiates  a  change  in  the  specified  <object>  object* s 
state  given  the  <input>_<typeJ7>,  <inpiit>_<type_8>, 
and  the  <input>^<type_9>. 

Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given_<inpiit>_<typeJ7>  is  the  <input>  <typeJ7>,  in  <typeJ7_units> 
Given_<input>_<type_S>  is  the  <input>  <typeJ8>,  in  <type_8_units> 
Given_<input>_<type_9>  is  the  <input>  <type_9>,  in  <type_9_units> 


procedure  G€t_<Output>_<State_l>_Prom 
(A_<Obj©ct>  :  in  <Object>; 

Returmng_<Output>_<Type_l>  :  out  Set.<Type_l>; 
Retuming_<Output>_<Type_2>  :  out  Set.<Type_2>; 
Retuming_<Output>_<Type_3> :  out  Set<Type_3>); 

—  I  Description: 

~  I  Initiates  a  report  of  the  specified  <object>  object*s 

—  I  state  returning  the  <output>_<type_l  >, 

—  I  <output>_<type_2>,  and  the  <outpui>_<type_3>. 


—  I  Pcuxuneter  Description: 

—  I  A_<object>  identifies  the  <object>  whose  state  is  needed. 

—  I  Retuming_<output>_<type_l>  is  the  <output>_<type_l> portion 

~  I  of  <object>  object* s  states  in  <type_ljunits> 

—  I  Returning _<output>_<type_2>  is  the  <output>_<type J2>  portion 

~  I  of  <object>  object*s  states  in  <type_2_units> 

—  I  Returning ^<output>_<type_3>  is  the  <ouiput>_<type_3>  portion 

~  I  of  <object>  objecfs  state,  in  <type_3junits> 


procedure  Gret_<C>iitput>_<State_2>_Prom 
(A_<Object>  :  in  <Object>; 

Ret\iming_<Output>_<Type_4>  :  out  Set.<Type_4>; 
Retuiiiing_<Output>_<Type_5>  :  out  Set.<Type_5>; 
Retummg_<Output>_<Type_6>  :  out  Set.<Type_6>); 

—  I  Description: 

~  I  Initiates  a  report  of  the  specified  <object>  object*s 
~  I  state  returning  the  <output>^<type_4>, 

—  I  <output>_<typeJ5>,  and  the  <output>_<typejS>. 
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Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  needed. 
Retuming_<output>_<type_4>  is  the  <output>_<type_4>  portion 
of  <object>  object's  state,  in  <type_4junits> 
Retuming_<output>_<type_5>  is  the  <output>_<type_5>  portion 
of  <object>  object's  state,  in  <type_5_units> 
Retuming_<output>_<type_6>  is  the  <output>_<typeJS>  portion 
of  <object>  object's  state,  in  <typejB^units> 


procedure  Get_<Output>_<State_3>_Prom 
(A_<Object>  :  in  <Otgect>; 

RetuiTiing_<Output>_<Type_7>  :  out  Set.<T3rpe_7>; 
Ret\iming_<Output>_<Type_8>  :  out  Set.<T3rpe_8>; 
Retuming_<Output>_<Type_9>  :  out  Set.<Type_9>); 

^ I «««*««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««« 

“I  Descriptioju 

—  I  Initiates  a  report  of  the  specified  <object>  object's 

—  I  state  returning  the  <output>^<typeJ7>, 

—  I  <output>_<type_8>,  and  the  <output>_<type_9>. 


Parameter  Description: 

A_<object>  identifies  the  <jobject>  whose  state  is  needed. 
RetumingjC.output>_<typeJ7>  is  the  <output>_<typeJ7>  portion 
of  <object>  object's  state,  in  <type^7^units> 
Retuming_<output>_<type_8>  is  the  <output>_<typeJ>  portion 
of  <object>  object's  state,  in  <type_8junits> 
Retuming_<output>_<type_9>  is  the  <output>_<type_9>  portion 
of<object>  object's  state,  in  <type_9_units> 


procedure  Give_<Attribute_l>_To  (A_<Object>  :  in  <Object>; 

Given_<Attribute_l>  :  in  <Attribute_l>); 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  <object>  object's 

—  I  state  given  the  <attribute_l>. 


—  I  Parameter  Descrip tioTu 

—  I  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

—  I  Given j<attribute_l>  is  the  <aitrihute_l>,  in  <attribute_l_units> 


procedure  Give_<Attribute_2>_To  ( 

A_<Object>  :  in  <01:!j©ct>;  Given_<Attribute_2>  :  in  <Attribute_2>); 

^  I  %4t***>tt*********************************************************** 

—  I  Description: 

- 1  Initiates  a  change  in  the  specified  <object>  object's 
••  I  state  given  the  <attribute_2>. 


—  I  Parameter  Description: 

—  I  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

—  I  Given_<attribute_2>  is  the  <attribute_2>,  in  <attribute_2junits> 

^  I  ^ttuti^itutututi********************************************************* 


procedure  Give_<Attribute_3>_To  (A_<Object>  :  in  <Object>; 

Given_<Attribute_3> :  in  <Attribute_3>); 

^ I ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««« 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  <object>  object's 

—  I  state  given  the  <attribuie_3>. 


—  I  Parameter  Description: 

-  I  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
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—  I  Given_<attribute_3>  is  the  <attributej>,  in  <attribute_3junits> 


pragma  Inline  (Give_<Input>_<State_l>_To, 

Get_<Output>_<State_l>_From, 
Gi  ve_<Input>_<S  tate_2>_To , 

Get_<Output>_<State_2>_Froin, 

Give_<Input>_<State_3>_To, 

G«t_<Output>_<State_3>_From, 

Give_<:Attribute_l>_To, 

Give_<Attribute_2>_To, 

Give_<:Attribut©_3>_To); 

private 

type  <Object>_Representation; 

—  incomplete  type,  defined  in  package  body 

type  <Object>  ie  accese  <Object>_Representation; 

—  pointer  to  an  <object>  representation 

end  <0bject>_0l5’ect_Manager; 


pragma  Page; 
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****i$*m*********************************************************m 


••  I  Module  Name: 

—  I  <object>  Object  Manager 

- 1  Module  Type: 

—  I  Package  Body 


Module  Description: 

The  Engine  <jobject>  object  manager  provides  a  means  to  create 
an  <object>  object  via  the  New_<object>  entry  and  returns 
an  identification  for  the  <object>,  which  is  to  be  used  when 
updating  I  accessing  the  <object>  objects  state  as  described  below. 

The  Engine  <jobject>  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Give_<input>_<state_l  >_To 

2)  Give_<input>jCstateJl>jro 

3)  Give_<input>^<state_3>_To 

4)  Give_<attribute_l>jro 

5)  Give_<attribute_2>_To 

6)  Give_<attributeJ3>_To 

entries,  requiring  the  following  external  state  information: 


1)  <input>_<type^l> 
<input>_<type_2> 

<input>_<type_3> 

2)  <input>_<type_4> 
<inp  ut>_<iypeJ5> 

<inp  ut>^<typejS> 

3)  <input>_<typeJ7> 
<inp  ut>jCtype^8> 

<input>_<type_9> 

4)  <attribute_l> 

5)  <attribute_2> 

6)  <attribute_3> 


<type_l_units> 
<type _2_units> 
<type_3junits> 
<typejijunits> 
<typej5juniis> 
<typejSjLL  nits> 
<iypejl jinits> 
<type_8jj,niis> 
<type_9  _units> 
<attribute_l_units> 
Kattribute  Jl_umts> 
^attribute  3junits> 


The  Engine  <object>  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get_<output>_<state_l> J'rom 

2)  Get_<output>_<state_^>  J'rom 

3)  Get_<output>_<stateJ3> ^rom 

entries,  yielding  the  following  internal  state  information: 

1)  <output>_<typeJi>  <typeji_units> 

<type_2_uniis> 

<typeJ3  jj,nits> 

<type_4jLinits> 

<type_5_units> 

<typejS_units> 

<typejl junits  > 

<type_8_units> 

<iype_9jLinits> 


<o  utput>_<type_2> 
<outp  ut>_<type_3> 

2)  <output>^<type^4> 
<outp  ut>_<type_5> 
<0  utp  ut>_<type_$> 

3)  <output>_<type_7> 
<outp  ut>_<type_8> 
<0  utp  ut>_<typej9> 


References: 

Design  Documents: 


Testing  and  Validation: 

none 

Notes: 

none 


Modification  History: 
24Aug87  cpp  Creation 
13Jul88  kl  Modified 
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—  I  Distribution  and  Copyright  Notice: 

“  1  Distribution  unlimited 

—  I  No  warranty  is  implied, 

—  I  Disclaimer. 

—  I  *'This  work  was  sponsored  by  the  Department  of  Defense. " 


package  body  <Object>_Object_Manager  i» 

t3rpe  <Object>_Repre8entation  im 
record 

<Input>_<Type_l>  :  Set.<Type_l>  ;=  ??; 
<Input>_<Type_2>  :  Set.<Type_2>  :=  ??; 
<Input>_<Type_3> :  Set<Type_3>  :=??; 
<Jnput>_<Type_4>  :  Set,<Type_4>  :=  ??; 
<Input>_<Ty^_5>  :  Set<Type_5>  :=  ??; 
<Input>_<Ty^_6>  ;  Set.<Type_6>  :=  ??; 
<Input>_<Type_7>  :  Set.<Type_7>  :=  ??; 
<Input>_<Type_8>  :  Set,<Type_8>  :=  ??; 
<Input>_<Type_9>  :  Set.<T3rpe_9>  :=  ??; 
The_<Attribute_l>  :  <Attribute_l>  :=  ??; 
The_<Attribute_2>  :  <Attribute_2>  :=  ??; 
The_<Attribute_3>  :  <Attribute_3>  :=  ??; 
<Output>_<Type_l>  :  Set.<Type_l>  :=  ?? 
<Output>_<'l9p®-2>  :  Set<Type_2>  :=  ?? 
<Output>_<Type_3>  :  Set.<'l9p«-3>  :=  ?? 
<Output>_<Type_4>  :  Set<Type_4>  :=  V 
<Output>_<'iype_5>  :  Set.<Type_5>  :=  ?? 
<0utput>_<Type_6>  :  Set,<Type_6>  :=  ?? 
<Output>_<Type_7>  :  Set.<Type_7>  :=  71 
<Output>_<Type_8>  :  Set.<'iype_8>  :=  V 
<Output>_<T3rpe_9>  :  Set.<Type_9>  :=  V 
end  record  ; 


function  New_<Object>  return  <Object>  im 
~l  Description: 

—  I  This  function  returns  a  pointer  to  a  new  <object>  object 
~  I  representation.  This  pointer  will  be  used  to  identify 
~  I  the  object  for  state  update  and  state  reporting  purposes. 


Parameter  Description: 

return  <object>  which  is  an  access  to  a  <object>  object. 


—  I  Notes: 

—  I  none 

_  I  %*%*%*%%%%%%%%4,%4t**************4t ***************%%*%%%%%%*%%**%*** 


begin 

—  function  body  goes  here 

RETURN  nuU; 
end  New_<Object>; 


procedure  Give_<Input>_<State_l>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_l>  :  in  Set.<T3rpe_l>; 
Given_<Input>_<T3rpe_2> :  in  Set.<Type_2>; 
Given_<Input>_<T3rpe_3>  :  in  Set.<Type_3>)  is 

.. I ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 
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-I  Description: 

1  Initiates  a  change  in  the  specified  <object>  object* s 
- 1  state  given  the  <input>_<type_l  >,  <input>_<type_2>, 

- 1  and  the  <input>_<typ€_3>. 


Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given^<inpiU>_<type^l>  is  the  <input>  <type_l>,  in  <type_ljunits> 
Given_<input>_<type_2>  is  the  <input>  <type_2>,  in  <type_2junits> 
Given_<input>_<iypeJ3>  is  the  <input>  <type_3>,  in  <typ€_3_units> 


—  \  Notes: 

—  I  none 

^  I  *********************************************t)t******************* 


begin 
null ; 

—  procedure  body  goes  here 
end  Give_<Input>_<State_l>_To; 


procedure  Give_<Input>_<State_2>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_4>  :  in  Set,<T3^e_4>; 
Given_<Input>_<Type_5>  :  in  Set.<Type_5>; 
Givein_<Input>_<Type_6>  :  in  Set.<Type_6>)  is 

Description: 

Initiates  a  change  in  the  specified  <object>  object*s 
state  given  the  <input>_<type_4>t  <input>_<type_5>, 
and  the  <input>_<iype_6>. 

Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given_<input>_<typeji>  is  the  <input>  <type_4>,  in  <type_4_unit8> 
Given _<inpiU>_<typeJ5>  is  the  <input>  <typeJS>f  in  <type_5_units> 
Given_<input>_<type_6>  is  the  <input>  <type_6>,  in  <type_6junits> 

Notes: 
none 


begin 
null ; 

—  procedure  body  goes  here 
end  Give_<Input>_<State_2>_To; 


procedure  Give_<Input>_<State_3>_To  (A_<Object>  :  in  <Object>; 

Given_<Input>_<Type_7>  :  in  ^t.<Type_7>; 
Given_<Input>_<Type_8>  :  in  S€t.<Type_8>; 
Given_<Input>_<Type_9>  :  in  Set.<Type_9>)  is 

Description.* 

Initiates  a  change  in  the  specified  <obJect>  object* s 
state  given  the  <input>_<type_7>t  <input>_<type_8>t 
and  the  <inpui>_<type_9>. 

Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given_<input>_<type_7>  is  the  <input>  <typeJ7>,  in  ctypejl junits> 
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Given_<input>^<typeJS>  is  the  <input>  <typeJ8>,  in  <typeJ8junits> 
Given _<input>_<type_9>  is  the  <input>  <type_9>,  in  <typeJ9jtinits> 


Notes: 


none 

****************************************** . 


„  ******************* 


begin 
null ; 

~  procedure  body  goes  here 
end  Give_<Input>_<State_3>_To; 


procedure  Get_<Output>_<State_l>_From 
(A_<Object>  :  in  <Object>; 

Returning_<Output>_<Type_l>  :  out  Set.<Type_l>; 
Retuming_<Output>_<Type_2>  :  out  Set.<Type_2>; 
Retuming_<Output>_<Type_3>  :  out  S€t.<Type_3>)  is 

I  ***************************************************************** 

-I  Description: 

—  I  Initiates  a  report  of  the  specified  <object>  object's 

—  I  state  returning  the  <output>_<type_l  >, 

~  I  <output>_<type_2>,  and  the  <output>_<type_3>. 


Pcuximeter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  needed. 
Returning _<output>jCiype^l>  is  the  <output>_<type_l> portion 
of  <obJect>  object's  state,  in  <type_l  junits> 
Retuming_<output>_<type_2>  is  the  <output>_<:type J2>  portion 
of  <object>  object's  state,  in  <typej2^units> 
Returning_<output>_<type_3>  is  the  <joutput>_<typeJ3>  portion 
of  <object>  object's  state,  in  <typeJ3_units> 


Notes: 


none 

***************************************************************** 


begin 
null ; 

—  procedure  body  goes  here 

Retumiiig_<Output>_<Type_l>  :=  ??; 
Returnmg_<Output>_<'l9p«_2>  :=  ??; 
Returnmg_<Output>_<'I^e_3>  :=  ??; 
end  Get_<Output>_<State_l>_From; 


procedure  Get_<Output>_<State_2>_From 
(A_<Object>  :  in  <Object>; 

Returning_<Output>_<Type_4>  :  out  S€t.<Type_4>; 
Retuniing_<Output>_<Type_5>  :  out  Set.<Type_5>; 
Retuming_<Output>_<Type_6>  :  out  Set.<Type_6>)  is 

_ I  ***************************************************************** 

—  I  Description: 

~  I  Initiates  a  report  of  the  specified  <object>  object's 

—  I  state  returning  the  <output>_<type_4>, 

—  I  <output>_<type_5>,  and  the  <output>_<typej6>. 

- 1  Parameter  Description: 

~  I  A_<object>  identifies  the  <object>  whose  state  is  needed. 

—  I  Returning _<output>_<iypeji>  is  the  <output>_<typeji>  portion 


74 


CMU/SEI-88-TR-30 


—  I  of  <object>  object^s  state,  in  <type_4junits> 

—  I  Returning _<output>_<iyp€j5>  is  the  <output>_<typeJ5>  portion 

- 1  of  <object>  object's  state,  in  <typeJ5junits> 

- 1  Retuming_<output>_<typejS>  is  the  <output>_<typejB>  portion 

—  I  of  <object>  object's  state,  in  <typ€_6_units> 

—  I  Notes: 

—  I  none 


begin 
null ; 

—  procedure  body  goes  here 

Retiirning_<Output>_<Type_4>  :=  ?? 
R©tuming_<Output>_<Type_5>  :=  7? 
Returning_<Output>_<Type_6>  ;=  ?? 
end  Get_<Output>_<State_2>_FVom; 


procedure  Get_<C>utput>_<State_3>_Prom 
(A_<:Object>  :  in  <Olgect>; 

Retuming_<C>utput>_<Type_7>  :  out  Set,<Type_7>; 
Retuniing_<Output>_<iype_8>  :  out  Set.<Type_8>; 
Retuming_<Output>_<Type_9>  :  out  S«t.<Type_9>)  is 

Description: 

Initiates  a  report  of  the  specified  <object>  object's 
state  returning  the  <joutput>_<iype_7>, 

<output>_<type_8>,  and  the  <output>_<typ€_9>. 

Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  needed. 
Retuming_<output>_<type_7>  is  the  <output>_<type_7>  portion 
of  <object>  object's  state,  in  <type_7_UTiits> 

Returning _<output>_<iype_S>  is  the  <output>_<type_8>  portion 
of  <object>  object's  state,  in  <iypeJ8junits> 
Retuming_<output>_<type_9>  is  the  <joutput>_<iype_9>  portion 
of  <object>  object's  state,  in  <typej9_units> 

Notes: 
none 


begin 
null ; 

—  procedure  body  goes  here 

Retummg_<Output>_<Type_7>  :=  ?? 
Retumiiig_<Output>_<Type_8>  :=  ?? 
Retuniing_<Output>_<I^e_9>  :=  ?? 
end  Get_<Output>_<Stato_3>_FVom; 


procedure  Give_<Attribute_l>_To  (A^<Object>  :  in  <Object>; 

Given_<Attribute_l>  :  in  <Attribute_l>)  is 

~I  Description: 

~  I  Initiates  a  change  in  the  specified  <object>  object's 
—  I  state  given  the  <attribute_l>. 

-I 

-I  Parameter  Description: 


CMU/SEI-88-TR-30 


75 


—  I  A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 

—  I  Given_<attribute^l>  is  the  <attribute_l>,  in  <attribute_ljunits> 

“I  Notes: 

—  I  none 

__ I «««*«««« «««««««* «««««««««««« «««««« ««««««« «««««««««««« «««««««««««« 

begin 
nuJl ; 

~  procedure  body  goes  here 
end  Give_<Attribute_l>_To; 


procedure  Give_<Attribute_2>_To  ( 

A_<Object>  :  in  <Object>;  Given_<Attribute_2>  :  in  <Attribute_2>)  is 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  <object>  object*s 

—  I  state  given  the  <attribute_2>. 


Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given_<attribute_2>  is  the  <attribute J2>,  in  <attribute_2junits> 


—  I  Notes: 

—  I  none 


begin 
nuJl ; 

—  procedure  body  goes  here 
end  Give_<Attribute_2>_To 


procedure  Give_<Attribute_3>_To  ( 

A«<Object>  ;  in  <Obiect>;  Given_<Attribute_3>  :  in  <Attribute_3>)  is 

—  I  Description: 

~  I  Initiates  a  change  in  the  specified  <object>  object*s 
~  I  state  given  the  <attribute_3>. 


Parameter  Description: 

A_<object>  identifies  the  <object>  whose  state  is  to  be  changed. 
Given_<attribute_3>  is  the  <attributeJ3>,  in  <attributeJ3junits> 


- 1  Notes: 
~l  none 


begin 
nuJl ; 

—  procedure  body  goes  here 
end  Give_<Attribute_3>_To; 
end  <Object>_Object_Maiiager; 
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Appendix  C:  Engine  code 


The  Ada  code  that  follows  implements  a  simulator  Engine  system.  The  implementation  is 
complete  through  the  package  specifications.  The  intent  is  to  demonstrate  the  software  ar¬ 
chitecture  defined  by  the  paradigm  discussed  in  Chapter  4. 


C.l.  Package  Global_Types 


Module  Name: 

Global  Types 

Module  Type: 

Package  Specification 

Module  Purpose: 

provide  global  types  for  xise  throughout  the  simulator  code 


Module  Description: 

This  package  provides  global  types  for  use  throughout  the  simulator 
code.  The  types  include  those  necessary  for  compliance  with  the 
Boeing  AS^/P  Ada  code 

Type  Elxecution_Sequence  defines  the  frames  to  be  used  by  the 
executives  during  the  cyclic  execution  of  the  code 

References: 

Design  Documents: 
none 

User*s  Manual: 
none 

Testing  and  Vcdidation: 
none 

Notes: 

none 


Modification  History: 
24Apr87  kl  created 


Distribution  and  Copyright  Notice: 
Distribution  unlimited 
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No  warraiity  is  implied. 


—  I  Disclaimer: 

—  I  '’This  work  was  sponsored  by  the  Department  of  Defense. " 

^  I  ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦*♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦*♦♦**♦♦*♦♦♦**♦ 

package  Global_Types  is 

type  Execution_Sequence  is  (Frame_l_Mod\iles_Are_Executed, 
Prame_2_Mod\iles_Are_Executed, 
Frame_3_Mod\ile8_Are_Executed, 
Prame_4_Modules_Are_Executed, 
Prame_5_Mod\iles_Are_Executed, 
Prame_6_Modules_Are_Executed, 
Frame_7_Modules_Are_Executed, 
Prame_8_Modules_Are_Execiited); 

end  Global_T3rpes; 


C.2.  Package  Staiidard_Engineering_Types 


Module  Name: 

Standard  JSngineeringJTypes 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  defines  some  standard  engineering  symbols  and  units 
which  are  used  in  the  Flight _Fxecutive. 


Module  Description: 

The  standard  engineering  symbols,  thier  range  and  units  of  measure 
are  specified  in  this  package.  All  objects  and  types  in  the 
flight  system  which  are  represented  in  the  real  world  in  these  units 
should  be  derived  from  these  types.  New  derived  types  can  be  expressed 
as  follows: 

type  My^lark  is  new  Standard  JSngineeringJI^p€s,Blark; 

References: 

Design  Documents: 
none 

User^s  Manual: 
none 

Testing  and  Validation: 


Notes: 

none 


—  I  Modification  History: 

—  1  25AUG87  cpp  creation 

i  Distribution  tsnd  Copyright  Notice: 

—  I  Distribution  unlimited 

—  I  No  warranty  is  implied. 

••I  Disclaimer: 
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—  I  'TTiis  work  was  sponsored  by  the  Department  of  Defense. 

^  I  m%***mmm*****t(t*************************************************m* 


package  Staiidard_£ngineermg_Types  is 

type  Pressure  is  digits  6  range  0.0  ..  10000.0; 

~  pound  per  square  inch 

type  Temperature  is  range  300 ..  3000; 

—  degrees  Rankine 

type  Air^Flow  is  digits  4  range  0.0  ..  500.0; 

—  pounds  per  second 

type  Thrust  is  digits  6  range  0.0  ..  20250.0; 

—  pounds 

type  Rpm  is  range  0  ..  20000; 

—  revolutions  per  miriute 

t3rpe  Torque  is  range  0  ..  10000; 

—  pound  feet 

end  Standard_Engineering_Types; 


C.3.  Package  Bleed_Valve_Object_Maiiager 


Module  Name: 

Bleed  J/alvejDbject_Manager 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  manages  objects  which  simulate  the 
Engine  Bleed  J/alve  for  the  C-141  simulator. 

This  management  entails  creation  of  Bleed_yalve  object's 
update^  maintenance  of  its  states  and  state 
reporting  capabilities. 


Module  Description: 

The  Bleed J/alve  object  maiiager  provides  a  means  to  create 
an  Bleed_yalve  object  via  the  New^leedJValve  operation  and  returns 
an  identification  for  the  Bleed_yalve,  which  is  to  be  used  when 
updating  f  accessing  the  Bleed_Valve  object's  state  as  described  below. 

The  Bleed  J/alve  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Givejnlet JPlowJTo 

2)  Give^InletJPressureJTo 

operations,  requiring  the  following  external  state  information: 

1)  Inlet _Air_Flow  pounds  per  second 

2)  lnlet_Pressure  pounds  per  square  inch 

The  Bleed_Valve  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get JDischarge _Air JF'low _Prom 

2)  Get  JDischarge Jhessure J^rom 
operations,  yielding  the  following  internal  state  information: 

1)  Discharge _^ir  JPlow  pounds  per  second 

2)  DischargeJPressure  pounds  per  square  inch 

References: 
none 

—  I  Design  Documents: 
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none 

User*s  Manual: 
none 


Testing  and  Validation: 
none 


Notes: 

none 


—  1  Modification  History: 

~  I  24Aug87  cpp  Creation 
-I  ISJuiaa  kl  Modified 


Distribution  and  Copyright  Notice: 


Distribution  unlimited 


—  I  No  warranty  is  implied 

—  I  Disclaimer: 

—  1  ”This  work  was  sponsored  by  the  Department  of  Defense, " 

with  Standard_Engineeriiig_Type8; 


package  Bleed_Valve_0bject_Manag6r  is 


package  Set  renames  Standard_Engmeering_T7pes; 
type  Bleed_Valve  is  private  ; 

—  an  Bleed_yalve  is  an  abstraction  of  a  Bleed^Valve  within  an  Engine. 


function  New_Bleed_Valve  return  Bleed_Valve; 

~l  Description: 

—  I  This  function  returns  a  pointer  to  a  new  BleedJ/alve  object 

—  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


—  I  Parameter  Description: 

—  (  return  Bleed^Valve  which  is  an  access  to  a  Bleed_yalve  object. 

_  I  4^4^«4^4k4^«4^«4k4^4^«4^4^4^4^«4^4^4^«4^4^4^4^««4^4^4^4^4^4^«4^4^4^««4^««4^«««4^««4^««««««««4^««««« 


procedure  Give_Inlet_Air_Flow_To  (A_Bleed_Valve  :  in  Bleed_Valve; 

GivenJnlet_Air_Flow :  in  SetAir_Flow); 

I  «4^«4^«4^««4^««««4^«««4^4^««4^«4^4^4^4^«4^««4^«4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^4^«4^4^4^4^4^4^4^4^4^4^4^ 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  BleedJ/alve  object*s 

—  1  state  given  the  Inlet ^ir _Elow. 


~l  Parameter  Description: 

—  I  A_Bleed_Valve  identifies  the  Bleed^Valve  whose  state  is 

—  I  to  be  changed, 

—  I  Givenj[nlet^ir_Flow  is  the  Inlet  Air  J*low,  in  pounds  per  second 

^  I  «««««  4^4^  ««4^«««4^«4^4^4^4^4^4^4^4^4^«4^«4^4^«4^  4^  4^4^  «  4^4^  «4^««4^«  ««««««« 


procedure  Give_Inlet_Pressure_To  (A_Bleed_Valve  :  in  Bleed_Valve; 

Given_Inlet_Pressure  :  in  Set.Pressure); 

_  I  «««4^4^«««4^««4^««««4^«4^#4^4^«4^4k«««4^4lt4^4^4^«««««««««4^4^4^4^«4^4^««4^4^««4^«4^«4^««4k4^4it 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  BleedJ/alve  objects 
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state  given  the  Inlet _Pressure. 


Parameter  Description: 

AJBleed^alve  identifies  the  BleedJValve  whose  state  is 
to  be  changed. 

Given_Inlet_Pressure  is  the  Inlet  Pressure,  in  pounds  per 
square  inch 


procedure  Gret_Discharge_Air_Flow_From 
(A_Bleed_Valve  :  in  Bleed^Valve; 
Retuming_Discharge_Air_Flow  :  out  SetAir^Flow); 

^ I «««««♦««««««««««««««««««««««««««««««««««««««««««««««««««««««««««« 

Deacripfion; 

Initiaies  a  report  of  the  specified  Bleed_Valve  object^s 
state  returning  the  Discharge _>4ir_F/ou;. 

Parameter  Description: 

A_Bleed_Valve  identifies  the  Bleed  Valve  whose  state  is  rieeded. 
Retuming_Discharge^irJPlow  is  the  Discharge^ir _piow  portion 
of  Bleed  J/alve  ohjecVs  state,  in  pounds  per  second 


procedure  G€t_Discharge_Pressure_Prom 
(A_Bleed_Valve  :  in  Bleed^Valve; 
Retuming^Discharge^Presaure :  out  SetPresaure); 

^  I  **i^***%****>^*%>^i^itt************************************************ 

Description: 

Initiates  a  report  of  the  specified  Bleed_Valve  object's 
state  returning  the  Dischargejhressure, 

Parameter  Description: 

A^leed^alve  identifies  the  Bleed  J/alve  whose  state  is  rieeded. 
Returning  J)ischargeJ^ssure  is  the  Discharge  Jhressure  portion 
of  Bleed_yalve  object's  state,  in  pounds  per  square  inch 

«««««««««««««««««««««««««««««««««««««««««*«««««******«**««««**♦** 


pragma  Inline  (Give  Jnlet_Air_Flow_To,  Get_Discharge_Air_Flow_From, 
Give_Inlet_Pre8aure_To,  (3et_Discharge_Pressure_Prom); 


private 

type  Bleed_Valve_Repre8entation; 

—  incomplete  type,  defined  in  package  body 

type  Bleed_Valve  is  acceee  Bleed_Valve_Representation; 
~  pointer  to  an  Bleed_Valve  representation 

end  Bleed_V  ai ve_Obj  ect_M  anager; 


C.4.  Package  Burner_Object_Manager 

_ I  ***************************************************************** 

“1  Module  Name: 

~  I  Burner ^Objectjdanager 
-I 

“  I  Module  Type: 

—  I  Package  Specification 
-I 

—  I  Module  Purpose: 

—  I  This  package  manages  objects  which  simulate  the 
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Engine  Burner  for  the  C-141  simulator 
This  management  entails  creation  of  Engine  Burner  objects, 
update  and  maintenance  of  its  state,  and  finally  state 
reporting  capabilities. 


Module  Description: 

The  Erigine  Burner  object  manager  provides  a  means  to  create 
an  Burner  object  via  the  New  JBumer  entry  and  returns 
an  identification  for  the  Burner,  which  is  to  be  used  when 
updating !  accessing  the  Burner  objects  state  as  described  below. 

The  Engine  Burner  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Givejinlet ^irJTo 

2)  GiveJFuelJ'low JTo 

3)  GiveJSparkJTo 

entries,  requiring  the  following  external  state  information: 

1)  Inlet  ^Pressure  pounds  per  square  irudi 

Inlet  JTemperature  degrees  Rankine 
Inlet ^ir  J'low  pounds  per  second 

2)  The_Fuel_Flow  pounds  per  second 

3)  TheJSpark  joules 

The  Engine  Burner  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get _Pischarge _jAir_From 

entries,  yielding  the  following  internal  state  information: 

1)  Discharge  Jbessure  pounds  per  square  inch 
Discharge  JTemperature  degrees  Rankine 
Discharge _fiir_Flow  pounds  per  second 

References: 

none 

Design  Documents: 
none 

User's  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


—  I  Modification  History: 

—  I  24Aug87  cpp  Creation 
~l  13Jul88  kl  Modified 


—  I  DistribtUion  and  Copyright  Notice: 

~  I  Distribution  unlimited 

—  I  No  warranty  is  implied. 

—  \  Disclaimer: 

~  I  "This  work  was  sponsored  by  the  Department  of  Defense. " 

^  I ****«**«**«****««*«*««****«*«««*«««««««««««««««««««««*«««««««««««««««**««** 

with  Standard  EDgineering_Types; 
package  B\imer_Object_Manager  is 
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package  Set  renames  Standard_Engineering_Types; 
type  Burner  is  private  ; 

—  an  Burner  is  an  abstraction  of  a  Burner  within  an  Engine. 

type  Spark  is  (None,  Low,  High); 

--  burner  needs  only  to  know  relative  spark  size 


type  Fuel^Flow  is  (None,  Flowing); 

—  the  burner  needs  to  know  only  if  it  has  fuel  available 


function  New_Bumer  return  Burner; 

—  I  Deecription: 

- 1  This  function  returns  a  pointer  to  a  new  Burner  object 

—  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


—  I  Parameter  Description: 

- 1  return  Burner  which  is  an  access  to  a  Burner  object. 


procedure  GiveJnlet_Air_To  (A_Bumer  :  in  Burner; 

Given_Inlet_Pressure  :  in  Set.Pressure; 
GivenJnlet^Temperature  :  in  Set. Temperature; 
GivenJnlet_Air_Flow  :  in  SetAir^Flow); 

Description: 

Initiates  a  change  in  the  specified  B  umer  objects 
state  given  the  Inlet  _Pressuret  Inlet  ^Temperature, 
and  the  Inlet _MrJlow. 

Parameter  Description: 

A_Bumer  identifies  the  Burner  whose  state  is  to  be  changed. 

Given  JnletJTressure  is  the  Inlet  Pressure,  in  pounds  per 
square  irtch 

GivenJnletJTemperature  is  the  Inlet  Temperature,  in  degrees  Rankine 
Given_Inlet _Ai^J'low  is  the  inlet  air  flow,  in  pounds  per  second. 


procediure  (^t_Discharge_Air_Prom 
(A_Bumer :  in  Burner; 

Returning_Di8charge_Pres8ure :  out  Set.Pre8sure; 
Retuming_Di8charge_Temperat\ire :  out  SeLTemperature; 
Retuming_Di8charge_Air_Flow  :  out  Set-Air^Flow); 

Description: 

Initiates  a  report  of  the  specified  Burner  objects 
state  returning  the  Discharge_Pressure, 

Discharge  JTemperature,  and  the  Discharge _yiir  J'low. 

Parameter  Description: 

A_Bumer  identifies  the  Burner  whose  state  is  needed. 

Returning J)ischarge_Pressure  is  the  DischargeJPressure  portion 
of  Burner  object*s  state,  in  pounds  per  square  inch 
Returning J)ischarge JTemperature  is  the  Discharge  JTemperature  portion 
of  Burner  object's  state,  in  degrees  Rankine 
Returning J)ischarge_Air _Plow  is  the  Discharge _Alr_Flow  portion 
of  Burner  object's  state,  in  pounds  per  second 


procedure  Give_Fuel_Flow_To  (A_Bumer  :  in  Burner, 
Given_Fuel_Flow  :  in  FueLFlow); 
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Description: 

Initiates  a  change  in  the  specified  Burner  object’s 
state  given  the  Fuel _Flow. 


—  \  Parameter  Description: 

- 1  A_Bumer  identifies  the  Burner  whose  state  is  to  be  changed. 

—  I  Given  J’uelJ’low  is  the  Fuel_Flow,  in  pounds  per  second, 

^  I  *i^***it*********************************************************4i* 


procedure  Give_Spark_To  (A_Bumer  :  in  Burner;  Given_Spark  :  in  Spark); 
—  I  Description: 

-- 1  Initiates  a  change  in  the  specified  Burner  object’s 
- 1  state  given  the  Spark. 


—  I  Parameter  Description: 

- 1  A_Bumer  identifies  the  Burner  whose  state  is  to  be  changed. 

—  I  GivenjSpark  is  the  Spor^,  in  joules, 


pragma  Inline  (Give_Inlet_Air_To,  Get_Discharge_Air_From, 
Give_Fuel_Flow_To,  Gi ve_Spark_To ); 


private 

t3rpe  Bumer_Representation; 

—  incomplete  type,  defined  in  package  body 

type  Burner  is  access  Bumer^Representation; 

—  pointer  to  an  Burner  representation 

end  Bumer_Object_Manager; 


C.5.  Package  body  Biirner_Object_Manager 

^ I ««««««««««««««♦««*««««««««««««««««««««««««««««««««««««««««««««««« 

—  I  Module  Ncme: 

—  I  Burner  Object  Manager 

—  I  Module  Type: 

-- 1  Package  Body 


Module  Description: 

The  Engine  Burner  object  manager  provides  a  means  to  create 
an  Burner  object  via  the  New  burner  entry  and  returns 
an  identification  for  the  Burner,  which  is  to  be  used  when 
updating ! accessing  the  Burner  objects  state  as  described  below. 


—  I  The  Engine  Burner  object  manager  provides  a  means  to  update  the 

—  I  state  of  the  object  via  the: 

—  I  1)  Givejnlet _Airjro 

—  I  2)  GiveJ'uel _Flowjro 

“  I  3)  GivejSparkJTo 

—  I  entries,  requiring  the  following  external  state  information: 

—  I  1)  Inlet _Pressure  pounds  per  square  inch 

—  (  Inlet  JTemperature  degrees  Rankine 

—  (  Inlet _Air_Flow  pounds  per  second 

—  I  2)  TheJ'uelJ'low  pounds  per  second 
-I  3)  TheJSpark  joules 
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-- 1  The  Engine  Burner  object  manager  provides  a  means  of  obtaining 

—  I  state  information  via  the: 

~l  1)  GetJ)ischarge _>4tr_From 

—  I  entries,  yielding  the  following  internal  state  information: 

—  I  1)  Discharge JPres sure  pounds  per  square  inch 

—  I  Discharge JTemperature  degrees  Rankine 

—  I  Discharge ^_,Air_Flow  pounds  per  second 

—  I  References: 

—  I  Design  Documents: 

—  I  none 

~  1  Testing  cmd  VcdidcUion: 

~l  none 


Notes: 

none 


—  I  Modification  History: 

—  I  24Aug87  cpp  Creation 
-I  13Jul88kl  Modified 


—  I  DistribtUion  and  Copyright  Notice: 

—  I  Distribution  unlimited 


No  warranty  is  implied. 


—  I  Disclaimer: 

—  I  **This  work  was  sponsored  by  the  Department  of  Defense. 

^ I **♦««*♦**«*«***♦**♦**♦**♦**♦**♦♦♦«♦«*♦«««*****«*****«*«*«*****«** 


package  body  Bumer_Object_Manageris 

t3rpe  Bumer_Repre8entation  is 
record 

Inlet^Pressure  :  SetPressure  :=  0.0; 
Inlet^Temperature  :  Set. Temperature  :=  300; 
Inlet_Air_Flow  :  Set.Air_Flow  :=  0.0; 

The_Spark  :  Spark  :=  High; 

The_Puel_Flow  :  Fuel_Flow  :=  Flowing; 
DiBchaTge_Pre8«ure  :  Set.Pressure  :=  0.0; 
Discharge_Temperature  :  Set  Temperature  :=  300; 
DischaTge_Air_Flow  :  Set.Air^Flow  :=  0.0; 
end  record  ; 


function  New_Bumer  return  Burner  is 

^ I  ***************************************************************** 


Description: 

This  function  returns  a  pointer  to  a  new  Burner  object 
representation.  This  pointer  will  be  used  to  identify 
the  object  for  state  update  and  state  reporting  purposes. 


Parameter  Description: 

return  Burner  which  m  an  access  to  a  Burner  object. 


-I  Notes: 


.. I  ***************************************************************** 


begin 

~  function  body  goes  here 

RETURN  nuU; 
end  New_Bumer; 
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procedure  Give_Inlet_Air_To  (A_Bumer  :  in  Burner; 

Given_Inlet_Press\ire  :  in  Set.Pressure; 
Given_Inlet_Temperature  :  in  Set.Temperature; 
Given_Inlet_Air_Flow  ;  in  Set.Air^Flow)  is 

^  I  *******************«****«««***««««4^*«**««««4^««'««««««««««««««««««« 

Descripti^^n: 

Initiate;;  >  change  in  the  specified  BurTier  object*s 
state  given  the  InletJPressure,  Inlet  JTemperaturet 
and  the  Inlet ^irj'low. 

Parameter  Description: 

A_Bumer  identifies  the  Burner  whose  state  is  to  he  changed. 
Given_Inlet_Pressure  is  the  Inlet  Pressure,  in  pounds  per 
square  inch 

Given_Inlet_Temperature  is  the  Inlet  Temperature,  in  degrees  Rankine 
Givenjnlet ^irJFlow  is  the  inlet  air  flow,  in  pounds  per  second. 

Notes: 

.. I ***♦*♦♦*♦♦***♦***♦****♦*♦♦**♦*♦***♦**♦♦♦♦♦♦*♦♦♦♦♦♦♦♦*♦♦♦*♦♦♦♦♦*** 


begin 
null ; 

—  procedure  body  goes  here 
end  Give_Inlet_Air_To; 


procedure  Get_Discharge _jAir_Prom 
(A.Bumer :  in  Burner; 

Retuming_Di8charge_Pressure  :  out  Set.Pressure; 
Retuming^Discharge.Temperature :  out  Set.Temperature; 
Retuming_Di8charge_Air_Flow  :  out  Set.Air_Flow)  is 

Description: 

Initiates  a  report  of  the  specified  Burner  objects 
state  returning  the  Discharge  J^ssure, 

DischargeJTemperature,  and  the  Discharge ^Air JFlow. 

Parameter  Description: 

A _Bumer  identifies  the  Burner  whose  state  is  needed. 
ReturmingJJischargeJ^ssure  is  the  Discharge_Pressure  portion 
of  Burner  object^s  state,  in  pounds  per  square  inch 
RetumingJDischargeJTemperature  is  the  DischargeJTemperature  portion 
of  Burner  ohject*s  state,  in  degrees  Rankine 
RetumingJDischarge _Jdr_Flow  is  the  Discharge __Air _Plow  portion 
of  Burner  object*s  state,  in  pounds  per  second 

Notes: 


begin 
null ; 

~  procedure  body  goes  here 

Retuming_Discharge_Pressure  :=  0.0; 
RetuLming_Discharge_Temperature  :=  300; 
Retuming_Discharge_Air_Flow  :=  0.0; 
end  Get_Di8charge_Air_From; 


procedure  Give_Fuel_Flow_To  (A.Bumer  :  in  Burner; 
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Given.FueLFlow  :  in  Puel_Flow)  is 

—  I  Description: 

••  I  Initiates  a  change  in  the  specified  Burner  object* s 

—  I  state  given  the  Fuel  JFlow. 

—  I  Parameter  Description: 

- 1  A_Bumer  identifies  the  Burner  whose  state  is  to  he  changed, 

—  I  Given  J'uel _Fl’OW  is  the  Fuel  J'low,  in  pounds  per  second, 

- 1  Notes: 


***************************************************************** 


begin 
null ; 

~  procedure  body  goes  here 
end  Give_Fuel_Flow_To; 


procediire  Give_Spark_To  (A_Bumer  :  in  Burner;  Given.Spark  ;  in  Spark)  is 
^ ] ***************************************************************** 
Description: 

Initiates  a  change  in  the  specified  Burner  object*s 
state  given  the  Spark. 

Parameter  Description: 

A  JBumer  identifies  the  Burner  whose  state  is  to  be  changed. 

Given^Spark  is  the  Spark,  in  joules, 

Notes: 

***************************************************************** 


begin 
null ; 

—  procedure  body  goes  here 
end  Give_Spark_To; 
end  Bumer_Object_Manager; 


C.6.  Package  Diffuser_Object_Manager 


Module  Nome; 

Diffuser _Oh ject_Manager 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  manages  objects  which  simulate  the 
Engine  Diffuser  for  the  C-141  simulator. 

This  management  entails  creation  of  Diffuser  object* s 
update,  maintenance  of  its  state,  and  state 
reporting  capabilities. 

Module  Description: 
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The  Diffuser  object  manager  provides  a  means  to  create 
an  Diffuser  object  via  the  New _J)iffuser  operation  and  returns 
an  identification  for  the  Diffuser ^  which  is  to  be  used  when 
updating  I  accessing  the  Diffuser  object’s  state  as  described  below. 

The  Diffuser  object  manager  provides  a  means  to  updoi,^  the 
state  of  the  object  via  the: 

1)  Give_Inlet_Pressure_andjremperature_To 
2)  Give _Mach _Number_To 

operations,  requiring  the  following  external  state  information: 

1)  Inlet  JPressure  pounds  per  square  inch 
Inlet  JTemperature  degrees  Rankine 

2)  TheJdach_Number  <dimensionless> 

The  Diffuser  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get _Pischarge _^ir  J'rom 

operations,  yielding  the  following  internal  state  information: 

1)  Discharge  ^Pressure  pounds  per  square  inch 
Discharge  JTemperature  degrees  Rankine 
Discharge^irJ'low  pounds  per  second 

References: 

none 

Design  Documents: 
none 

User’s  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


—  I  Modification  History: 

—  I  24Aug87  cpp  Creation 

—  I  13Jul88  kl  Modified 


—  I  Distribution  €snd  Copyright  Notice: 

—  I  Distribution  unlimited 

—  I  No  warranty  is  implied, 

—  I  Disclaimer: 

—  I  ’This  work  was  sponsored  by  the  Department  of  Defense. " 

_  I  «««««««««««««««««*«««««««««*«««««««««*«««««««««««««««««««««««*««««**««««*** 

with  Standard_Eiigineermg_Type8; 
package  Oi£fuser_Object_Maxiager  ia 

package  Set  renames  Standard_£ngineermg_Types; 
type  Diffiiser  is  private  ; 

—  an  Diffuser  is  an  abstraction  of  a  Diffuser  within  an  Engine. 

type  Mach^Number  is  digits  3  range  0.00  ..  1.00; 

•^dimensionless> 

function  New^Difiiiser  return  Diffuser, 
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*%******************%******************************************** 


—  I  Description: 

—  I  This  function  returns  a  pointer  to  a  new  Diffuser  object 

—  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


Pammeter  Description: 

return  Diffuser  which  is  an  access  to  a  Diffuser  object. 

***************************************************************** 


procedure  Give Jnlet_Pressure_And_T empera ture_T o 
(A^Difiuser :  in  Difiuser; 

Given_Inlet_Pressure  :  in  Set.Pressure; 

Given  Jnlet^Temperature  :  in  Set.Temperature); 

^  I  ***************************************************************** 

—  \  Description: 

—  I  Initiates  a  change  in  the  specified  Diffuser  object's 

—  I  state  given  the  Inlet  ^Pressure,  Inlet  JTemperature. 


—  1  Parameter  Description: 

-- 1  Aj)iffuser  identifies  the  Diffuser  whose  state  is  to  be  changed. 

—  1  Given  Jnlet^Pressure  is  the  Inlet  Pressure^  in  pounds  per 

~  1  square  inch 

—  I  Given _Inlet  JTemperature  is  the  Inlet  Temperature,  in  degrees  Ranhine 


procedure  Get_Discharge_Air_Prom 
(A^Difiuser ;  in  DifRiser, 

Returning_Di8charge_Pre8sure  :  out  Set.Pres8ure; 
Retuming_Discharge_Temperature  :  out  Set.  Temperature; 
Retuming_Discharge_Air_Flow :  out  Set.Air_Flow); 

—  1  Description: 

—  I  Initiates  a  report  of  the  specified  Diffuser  object's 

—  I  state  returning  the  Discharge_Pressure, 

—  I  Discharge  JTemperature,  and  the  Discharge ^ir _Plow. 


—  1  Parameter  Description: 

—  I  A_Diffuser  identifies  the  Diffuser  whose  state  is  needed. 

—  I  RetujmxngJ^ischargeJ^ressure  is  the  Discharge Jhessure portion 

—  I  of  Diffuser  object's  state,  in  pounds  per  square  inch 

—  I  Returning J^ischarge JTemperature  is  the  Discharge  JTemperature  portion 

—  I  of  Diffuser  object's  state,  in  degrees  Rankine 

—  I  Returning J)ischarge_MrJ*low  is  the  Discharge^AirJ^low  portion 

“  I  of  Diffuser  object's  state,  in  pounds  per  second 

^  I  ***************************************************************** 


procedure  Give_Mach_Nuinber_To  (A^Difiuser  :  in  Diffuser; 

Given.Mach^Number :  in  Mach.Number); 

—  I  Description: 

—  1  Initiates  a  change  in  the  specified  Diffuser  object's 

—  1  state  given  the  Mach_Number. 

—  I  Parameter  Description: 

—  I  AJ)iffuser  identifies  the  Diffuser  whose  state  is  to  be  changed. 

—  I  GivenJMach  Jlumher  is  the  Mach  J^umber,  in  <dimensionless> 


praifma  Inline  (Give_Inlet_Pressure_And_Temperature_To, 
Get_Discharge_Air_Prom,  Give_Mach_Nuinber_To ); 


CMU/SEI-88-TR.30 


89 


private 

type  Diff\iser_Representation; 

—  incomplete  type,  defined  in  package  body 

type  Diffuser  is  access  Diffuser_Repre8€ntation; 

—  pointer  to  an  Diffuser  represerUation 

end  Diffu8er_0bject_Manager, 


C.7.  Package  Engine_Casing_Object_Manager 


*******************************%*%%%%%%%%%%*%%%%%%%%%%%%%*%***%%* 
Mo  dule  Name: 

Engine  jCas  ing_Object_Manager 

Module  Type: 

Package  Specification 

Module  Purpoee: 

This  package  manages  objects  which  simulate  the 
Engine  Engine  jCasing  for  the  C~141  simulator. 

This  management  entails  creation  of  Engine  JCasing  objects 
update,  maintenance  of  its  state,  and  state 
reporting  capabilities. 


Module  Deecription: 

The  Engine  JCasing  object  manager  provides  a  means  to  create 
an  Engine  JCasing  object  via  the  New  ^Engine JCasing  operation  and  returns 
an  identification  for  the  Engine  JCasing,  which  is  to  be  used  when 
updating  i  accessing  the  Engine  JCasing  ebjeeVs  state  as  described  below. 

The  Engine  jCasing  object  manager  provides  a  meaTis  to  update  the 
state  of  the  object  via  the: 

1)  Give J[nlet_Pres8urejro 

2)  Givejnlet ^ir J^lowJTo 

2)  GiveJnletJTemperatureJTo 
operatioTis,  requiring  the  following  external  state  information: 

1)  Inlet_Pressure  pounds  per  square  inch 

2)  Inlet ^irJPlow  pounds  per  second 
2)  Inlet  JTemperature  degress  Rankine 

The  Engine  jCasing  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  GetJ)ischarge_PressureJ^rom 

2)  Get Jlischarge J^lowJProm 

2)  Get JCischarge JTemperature  J'rom 
operations,  yielding  the  following  internal  state  information: 

1)  Discharge_Pressure  pounds  per  square  inch 

2)  Discharge _^irJF'low  pounds  per  second 
2)  Discharge  JTemperature  degress  Rankine 

References: 

none 

Design  Documents: 


User's  Manual: 
none 

Testing  and  Validation: 
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—  I  none 

—  I  Notes: 

—  I  none 


—  I  Modification  History: 

—  I  24Aug87  cpp  Creation 
-I  13Jul88  kl  Modified 


~  I  Distribution  and  Copyright  Notice: 

—  I  Distribution  unlimited 

—  I  No  warranty  is  implied 

—  I  Disclaimer: 

—  I  "TTiw  work  was  sponsored  by  the  Department  of  Defense. " 

__  I  «««««««««««««««««««««««**««««««««««**««**««««««««««*««««««*«««*««*«««««««*« 

with  Standard_Engineering_Type8; 
package  Engine_Casiiig_Object_Maiiager  is 
^  package  Set  renames  Standard_Engineeriiig_Types; 


t3rpe  Engine_Casing  is  private  ; 

—  an  EnginejCasing  is  an  abstraction  of  a  Engine  jCasing  within  an  Engine. 


function  New_Engine_Casing  return  Eiigine_Casmg; 

—  I  Description: 

—  I  This  function  returns  a  pointer  to  a  new  EnginejCasing  object 

—  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


—  I  Parameter  Description: 

—  I  return  EnginejCasing  which  is  an  access  to  a  EnginejCasing  object. 


procedure  Give_Inlet_Pre88ure_To  (A_Eiigine_Casing  :  in  Engine_Casmg; 
Given_Iiilet JEVessure  :  in  Set.Pres8ure); 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  EnginejCasing  object's 

—  I  state  given  the  Inlet _Pres8ure. 


—  I  Parameter  Description: 

—  I  A_Engif^^Casing  identifies  the  EnginejCasing  whose  state  is 
~  I  to  be  changed. 

—  I  Given _Inlet_Pressure  is  the  Inlet  Pressure,  in  pounds 

—  I  per  square  inch 


procedure  Give_Inlet_Air_Flow_To  (A-Engine_Casing  :  in  Engine_Casing; 
Given_Inlet_Air_Flow :  in  Set.Air_Flow); 

-I  DescHption: 

—  I  Initiates  a  change  in  the  specified  EnginejCasing  object's 

- 1  state  given  the  Inlet _Air  JFlow. 

—  I  Parameter  Description: 

••  1  A JEngine JCasing  identifies  the  EnginejCasing  whose  state  is 

I  to  be  changed. 
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—  I  Givenjnlet _jAir_Flow  is  the  Inlet  Air JF low,  in  pounds  per  second 

.. I  ***************************************************************** 


procedure  GiveJnlet_Temperature_To 

(A_Engine_Casing :  in  Engine_Casing; 
Given_Inlet_Temperatiire  :  in  Set.Temperature); 

^ I ***%**%*%%%%%%%%**%****%****%%*%**%***%%*%*%**%%*%%%*%**%****%%%% 

—  I  Description: 

1  Initiates  a  change  in  the  specified  Engine jCasing  object*s 

—  I  state  given  the  Inlet  JTemperature, 


—  I  PiMrameter  Description: 

—  I  A_Engine_Casing  identifies  the  EnginejCasing  whose  state  is 
~  I  to  be  changed. 

—  I  Given  JnletJTemperature  is  the  Inlet  Temperature,  in  degress  Rankine 

^  I  ***************************************************************** 


procedure  Get^Discharge^Preasure^Prom 

(A_Engine_Casing :  in  EnginejCasing; 
RetumingjDischarge_Pressure :  out  SetPressure); 

I  ***************************************************************** 
Description: 

Initiates  a  report  of  the  specified  EnginejCasirig  objects 
state  returning  the  DischargeJPressure. 

Parameter  Description: 

A  JSnginejCasing  identifies  the  Engine  jCasirig  whose  state  is  needed. 
RetumingJpischargeJPressure  is  the  Discharge_Pressure  portion 
of  Engine  _Casing  object's  state,  in  pounds  per  square  inch 

***************************************************************** 


procedure  Get_Di8chargejAirjFlow_Proin 

(AjEngine_Casing :  in  EnginejCasing; 
RetumingjDischargejAiTjFlow  :  out  SetAiTjFlow); 

I «««««««#«««««««««««««««««««««♦««««««««««««««««««««««««««««««««««« 

Description: 

Initiates  a  report  of  the  specified  EnginejCasing  object's 
state  returning  the  Discharge^irJ*low. 

Parameter  Description: 

A  JSnginejCasing  identifies  the  EnginejCasing  whose  state  is  needed. 
Returning JCischarge^AirJ'low  is  the  Discharge^AirJ'low  portion 
of  Engine  JCasiTig  object's  state,  in  pounds  per  second 

*******************%***%***%***%ik******************************** 


procedure  GetjI>ischargejTemperature_Prom 
(A^Engine  jCasing :  in  Engine_Casing; 
RehimingjDischargejTemperature :  out  Set.Temperature); 

_ I *******************************************%****%****%***%*%*%%*% 

Description: 

Initiates  a  report  of  the  specified  EnginejCasing  object's 
state  returning  the  Discharge JPemperature. 

Parameter  Description: 

AJSnginejCasing  identifies  the  Engine  JCasirig  whose  state  is  needed. 
Returning JCischargeJTemperature  is  the  Discharge JTemperature  portion 
of  Engine  JCasing  object's  state,  in  degress  Rankine 

*********************************************************t^****i^*t^ 


pragma  Inline  (Give_InletjPressurejTo,  GetjDischarge_Press\ire_From, 
Give_Inlet_Air_Flo w  jT o ,  Get_Discharge_Air_Flo w jFrom , 

Give  jinl et jT emperature ^To,  Get_Discharge_Temperature_From); 
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private 

type  Engine_Casing_Representation; 

—  incomplete  type,  defined  in  package  body 

type  Engine_Casing  is  access  Engine_Casing__Representation; 

—  pointer  to  an  Engine jCasing  representation 

end  Engine_Casing_Object_Manager; 


C.8.  Package  Exhaust_Object_Manager 


««««««««««***««*««*****«********«******«««*****«***«*«««*«*«««««« 
Module  Name: 

Exhaust  jDhject^aTiager 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  manages  objects  which  simulate  the 
Engine  E^aust  for  the  C-141  simulator. 

This  management  entails  creation  ofElxhaust  object*s 
update,  maintenance  of  its  state,  and  state 
reporting  capabilities. 


Module  Description: 

The  Elxhaust  object  manager  provides  a  means  to  create 
an  Elxhaust  object  via  the  New _^xhaust  operation  and  returns 
an  identification  for  the  Exhaust,  which  is  to  be  used  when 
updating  f  accessing  the  Exhaust  objecVs  state  as  described  below. 

The  Exhaust  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Give JnletJhessureJFo 

operations,  requiring  the  following  external  state  information: 

1)  Inlet  Jb^ssure  pounds  per  square  inch 

The  Exhaust  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  GetjyischargeJThrustJ'rom 

2)  Getjlgt jFrom 

3)  Get _^pr __From 

operations,  yielding  the  following  internal  state  information: 

1)  DischargeJThrust  pounds  per  square  inch 

2)  Egt  degrees  Rankine 

3)  TheJ^pr  <diemensionless> 

References: 

none 

Design  Documents: 
none 

User*s  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 
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—  I  Modification  History: 

- 1  24Aug87  cpp  Creation 

-I  13Jul88  kl  Modified 


Distribution  and  Copyright  Notice: 


Distribution  unlimited 


—  I  No  warranty  is  implied. 

—  I  Disclaimer: 

—  I  **This  work  was  sponsored  by  the  Department  of  Defense.  ** 

^  I  *************************************************************************** 

with  Standard_Engineering_Type8; 


package  £xhaust_Object_Manager  is 

package  Set  renames  Standard_Engineering_Types; 


type  Exhaust  is  private  ; 

~  an  Exhaust  is  an  abstraction  of  a  Exhaust  within  an  Engine. 

type  Epr  is  digits  2  range  1.2  ..  2.3; 

—  <dimensionless> 


function  New.Exhaust  return  Exhaust; 

_ I  ***************************************************************** 

~l  Description: 

~  I  This  function  returns  a  pointer  to  a  new  Exhaust  object 
—  I  represerUation.  This  pointer  will  he  used  to  identify 
~  I  the  object  for  state  update  and  state  reporting  purposes. 


—  I  Parameter  Description: 

—  I  return  Exhaust  whudi  is  an  access  to  a  Exhaust  object. 


procedure  Giye_Inlet_Pre8Sure_To  (A_Exhaust :  in  Exhaust; 

Givon^Inlet  JVessure  :  in  Set.Pressure); 

^ I  ***************************************************************** 


“  I  Description: 

—  I  Initiates  a  change  in  the  specified  Exhaust  object's 
~  I  state  given  the  Inlet  ^Pressure. 


—  I  Parameter  Description: 

—  I  A_Exhaust  identifies  the  Exhaust  whose  state  is  to  be  changed. 

—  I  Given^Inlet^Pressure  is  the  Inlet  Pressure,  in  pounds  per 

—  I  square  inch 

^ I  ***************************************************************** 


procedure  Get_Discharge_Thrust_From 
(A.Exhaust :  in  Exhaust; 

Retuming_Discharge_Thruat :  out  Set.PressurG); 

—  I  Description: 

—  I  Initiates  a  report  of  the  specified  Exhaust  object's 

—  I  state  returning  the  Discharge  JThrust. 


Parameter  Description: 

A  Jlxhaust  identifies  the  Exhaust  whose  state  is  needed. 
Returning  ^Discharge JThrust  is  the  Discharge  JThrust  portion 
ofEhchaust  object's  state,  in  pounds  per  square  inch 
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^  I  4i4r***4i*******4nli*4nti***********4r**4t*****4t************************** 


procedure  Get_Egt_From  (A_Exhaust :  in  Exhaust; 

Retunung_Egt :  out  Set. Temperature); 

—  I  Description: 

—  I  Initiates  a  report  of  the  specified  Blxhaust  object*s 

—  I  state  returning  the  Egt, 


—  \  Parameter  Description: 

—  I  AJlxhaust  identifies  the  Blxhaust  whose  state  is  needed. 

—  I  RetumingJSgt  is  the  Egt  portion 

~  I  of  Exhaust  objedt*s  state^  in  degrees  Rankine 

__  I  li**%‘li*******4t******4t4t*****4t***********4t**4t*4t ********************* 


procedure  Get_Epr_Prom  (A_Exlia\ist :  in  Exhaust;  Retuming^Epr  :  out  Epr); 

I  *^i4iii**^i**ii***************************^i*^i*****************^i******* 

>- 1  Description: 

~  I  Initiates  a  report  of  the  specified  Blxhaust  object* s 

—  I  state  returning  the  Epr. 

—  I  Parameter  Description: 

—  I  A^xhaust  identifies  the  Exhaust  whose  state  is  needed. 

—  I  Returning  Jlpr  is  the  Epr  portion 

~  I  of  Blxhaust  object*s  state,  in  <diemensionless> 

^ I **ii***************^********************************************** 


pragma  Inline  (GiveJnlet_Pressure_To,  Get_Discharge_Thrust_From, 
G€t_E?t_From,  Get^Epr.From); 


private 

t3rpe  Exhaust_Kepresentation; 

—  incomplete  type,  defined  in  package  body 

type  Exhaust  is  access  Exhaust_Representation; 
pointer  to  an  Exhaust  representation 

end  Exhaust_Object_Manager; 


C.9.  Package  Fan_Duct_Object_Manager 


***************************************************************** 
Module  Ncane: 

Fan  _Puct_Object_Manager 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  manages  objects  which  simulate  the 
Engine  Fan_Duct  for  the  C-141  simulator. 

This  management  entails  creation  of  Fan _Puct  object*s 
update,  maintenance  of  its  state,  and  state 
reporting  capabilities. 


’•  I  Module  Description: 

- 1  The  Fan_J)uct  object  manager  provides  a  means  to  create 
- 1  an  Fan _J)uct  object  via  the  New _Fan _Puct  operation  and  returns 

- 1  an  identification  for  the  Fan _Puct,  which  is  to  be  used  when 
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updating !  accessing  the  Fan_Duct  objects  state  as  described  below. 


The  Fan_Duct  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Give_lnlet_Pressure_To 

operations,  requiring  the  following  external  state  information: 
1)  Inlet  JPressure  pounds  per  square  inch 

The  Fan  J)uct  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get_Dischargejrhrust_From 
operations,  yielding  the  following  inteimal  state  information: 
1)  Discharge JThrust  pounds 

References: 


Design  Documents: 
none 

User's  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


—  I  Modification  History: 

~  I  24Aug87  cpp  Creation 
^1  13Jul88  kl  Modified 


Distribution  and  Copyright  Notice: 


Distribution  unlimited 


—  I  No  warranty  is  implied. 

—  I  Disclaimer: 

—  I  This  work  was  sponsored  by  the  Department  of  Defense. " 

I *********************************************************%%********%%%%*%%% 

with  Standard_Engmeering_Types; 
package  Fan_l>uict_Object_Manager  is 

package  Set  renames  Standard^Engineering^Types; 


type  Fan^Diict  ut  private  ; 

—  an  Fan_Duct  is  an  abstraction  of  a  Fan_Duct  within  an  Engine. 


function  New_Fan_rhict  return  Fan^Duct; 

—  I  Description: 

~  I  This  function  returns  a  pointer  to  a  new  Fan^Duct  object 
~  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 


Parameter  Description: 

“  I  return  Fan  J)uct  which  is  an  access  to  a  FanJ)uct  object. 

^ I ***************************%*******%***********%******%********%* 
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procedure  GiveJnlet_Press\ire_To  (A_Fan_Duct :  in  Fan_I>uct; 

Given_Inlet_Pressure  :  in  Set.Pressure); 

1 111/11*111************************************************************* 

—  \  Description: 

—  I  Initiates  a  change  in  the  specified  Fan_Duct  object's 

—  I  state  given  the  Inlet  JPressure. 

—  I  Parameter  Description: 

••  I  A_Fan  JDuct  identifies  the  Fan_Duct  whose  state  is  to  be  changed. 

—  I  Given_Inlet_Pressure  is  the  Inlet  Pressure,  in  pounds  per 

—  I  square  inch 

^ I ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 


procedure  Get_Discharge_Thrust_From 
(A_Fan_Duct :  in  Fan_Duct; 

Retuming_Di8charge_Thrust :  out  Set. Thrust); 

I ************^**************************************************** 

—  I  Description: 

—  I  Initiates  a  report  of  the  specified  Fan J)uct  object's 

—  I  state  returning  the  Discharge  JThrust. 


Parameter  Description: 

A_Fan  JDuct  identifies  the  Fan  JDuct  whose  state  is  needed. 
Returning  J)ischarge_Thrust  is  the  Discharge  JThrust  portion 
ofFanJDuct  object's  state,  in  pounds 

♦♦«««««««««««««««««««««««««««««««««««««««««««««««««««««««««♦««««« 


pragma  Inline  (Give_Inlet_Pres8ure_To,  Get_Discharge_Thrust_From); 
private 

type  Fan_Duct_Repreeentation; 

—  incomplete  type,  defined  in  package  body 

type  Fan_Duct  ia  acceaa  Fan_Duct_Repre8entation; 

—  pointer  to  an  Fan  J^uct  representation 

end  Fan_Duct_Object_Manager; 


C.IO.  Package  Rotorl_Object_Manager 


_ I ««««««««««««««««**«*«****«*««*«******«««******««««««««*«««««*«««« 

—  I  Module  Name: 

—  I  Rotor  ljObject_Manager 


Module  Type: 

Package  Specification 


->l  Module  Purpose: 

~  I  This  package  manages  objects  which  simulate  the 

—  I  Engine  Rotorl  for  tAc  C-141  simulator. 

—  I  This  management  entails  creation  of  Rotorl  object's 

—  I  update,  maintenance  of  its  state,  and  state 

—  I  reporting  capabilities. 


Module  Description: 

The  Rotorl  object  manager  provides  a  means  to  create 
an  Rotorl  object  via  the  New_Rotorl  operation  and  returns 
an  identification  for  the  Rotorl,  which  is  to  be  used  when 
updating  i accessing  the  Rotorl  object's  state  as  described  below. 
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—  I  The  Rotor  1  object  manager  provides  a  means  to  update  the 

—  I  state  of  the  object  via  the: 

- 1  1)  Give_Fanl_Inlet_Air_To 

—  I  2)  Givejrurbinel_Inlet ^MrJTo 

~  I  operations,  requiring  the  following  external  state  information: 

—  I  1)  FanlJ[nlet_Pressure  pounds  per  square  inch 
~  I  FanlJlnletJTemperature  degrees  Rankine 

-- 1  Fanl_Inlet_Air _Flow  pounds  per  second 

—  I  2)  Turbinel_lnlet_Pressure  pounds  per  square  inch 
~l  TurbinelJnletJTemperature  degrees  Rankine 

~  I  Turbineljnlet _Flow  pounds  per  second 

—  I  The  Rotor  1  object  manager  provides  a  means  of  obtaining 

—  I  state  information  via  the: 

—  I  1)  Get_Fanl_Discharge rom 

~  I  2)  Getjrurbinel_Discharge^ir_From 

- 1  3)  Get_Rpm_From 

- 1  4)  Get_yibration_From 

—  I  operations,  yielding  the  following  internal  state  information: 

—  I  1)  Fanl_Discharge_Pressure  pounds  per  square  inch 

~  I  Fanl _pischarge_Temperature  degrees  Rankine 

—  I  Fanl _J)ischarge _Air_Flow  pounds  per  second 

—  I  2)  Turbinel_Discharge_Pres8ure  pounds  per  square  inch 

—  I  Turbinel_Discharge_Temperature  degrees  Rankine 

—  I  Turbinel _Discharge _Ai^J*low  pounds  per  second 

~  I  3)  Thejlpm  rpm 

~l  4)  TheJ/ibration  mils 

~l  References: 

~l  none 

-I  Design  DocumerUs: 

- 1  none 


—  I  User’s  Manual: 

~  I  none 

—  I  Testing  and  Validation: 

—  I  none 


Notes: 

none 


—  I  ModificaHon 
- 1  24Aug87 

- 1  13Jul88  kl 


History: 
cpp  Creation 
Modified 


—  I  Distribution  and  Copyright  Notice: 

—  I  Distribution  unlimited 

~  I  No  warranty  is  implied 

~  I  Disclaimer: 

—  I  ’’This  work  was  sponsored  by  the  Department  of  Defense. " 

_  I  *%ttttit%%^it**itt**)tt**********************************m************************m** 

with  Standard^Engineering^Types; 


package  Rotor l_Object_Manager  is 


package  Set  renames  Standard_Engineering_Types; 
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type  Rotorl  is  private  ; 

-  an  Rotorl  is  an  abstraction  of  a  Rotorl  within  an  Engine. 

type  Vibration  is  range  0  ..  5; 

—  mils 


function  New_Rotorl  rettim  Rotorl; 

^  I  «««««*«««««««««««««««♦«««««««««««««««««««««♦«««««««♦♦♦«♦««♦«««♦♦♦ 

--I  Description: 

—  I  This  function  returns  a  pointer  to  a  new  Rotorl  object 

—  I  representation.  This  pointer  will  be  used  to  identify 

—  I  the  object  for  state  update  and  state  reporting  purposes. 

—  I  Parcmeter  Description: 

- 1  return  Rotorl  which  is  an  access  to  a  Rotorl  object. 

^  I « *«*«4^«*«**  *4^4^**  «««««*  ««*«♦««««««««««««  ««««««« 


procedure  Give_Fanl_Inlet_Air_To 
(A_Rotorl :  in  Rotorl; 

Given_Fanl_Inlet_Pressure  :  in  Set.Pressure; 
Given_Fanl_Inlet_Temperature  :  in  Set  Temperature; 
Given_Fanl_Inlet_Air_Flow ;  in  Set.Air_Flow); 

—  I  Description: 

—  I  Initiates  a  change  in  the  specified  Rotorl  objects 

- 1  state  given  the  Fanljnlet __Pres8ure,  Fanl_Inlet_Temperature, 

~l  and  theFanlJnlet _jAir _Flow. 


~1  Parameter  Description: 

—  i  AJlotorl  identifies  the  Rotorl  whose  state  is  to  be  changed. 

- 1  Given _F an l_Inlet_Pressure  is  the  Inlet  Pressure,  in  pounds 

~  I  per  square  inch 

~1  Given _Fanl_Inlet_Temperature  is  the  Inlet  Temperature, 

-- 1  in  degrees  Rankine 

- 1  Given _Fanl_Inlet ^jAir_Flow  is  the  Inlet  Air_Flow,  in  pounds 

~  1  per  second 


proce  dure  Give^Turbine  1_I  nlet_Air_To 
(A_Rotorl :  in  Rotorl; 

Given_Turbinel_Inlet_Preasure  :  in  Set.Pressure; 
Given_Turbinel_Inlet_Temperature  :  in  Set  Temperature; 
Given_TurbmelJ[nlet_Air_Flow  :  in  Set.Air_Flow); 


Description: 

Initiates  a  change  in  the  specified  Rotorl  objects 

state  given  the  T\irbinel_Inlet_Pressure,  Turbine l_Inlet_Temp€rature, 

and  the  Turbine  1^1  nlet ^ir _Flow. 


—  I  Parameter  Description: 

—  I  A_Rotorl  identifies  the  Rotorl  whose  state  is  to  be  changed. 

—  I  Given_Turbinel_Inlet_Pressure  is  the  Inlet  Pressure, 

—  I  in  pounds  per  square  inch 

—  I  Given_Turbinel_Inlet_Temperature  is  the  Inlet  Temperature, 
- 1  in  degrees  Rankine 

—  I  Given_Turbinel_Inlet_Air_Flow  is  the  Inlet  Air_Flow,  in 

—  I  pounds  per  second 


procedure  G€t_Fanl_Discharge_Air_From 
(A_Rotorl :  in  Rotorl; 

Retuming_Fanl_Discharge_Presaure  :  out  Set.Pressure; 
Retuming_Fanl_Discharge_Temp€rature  :  out  Set  Temperature; 
Retuming_Fanl_Discharge_Air_Flow  :  out  Set  Air_Flow); 
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Description: 

Initiates  a  report  of  the  specified  Rotor  1  object's 
state  returning  the  Fan  l_Discharge_Pres sure, 

Fanl_Discharge_Temperature,  and  the  Fanl _Pischarge_AirJ'low. 


—  I  Parameter  Description: 

—  I  AJRotorl  identifies  the  Rotorl  whose  state  is  needed. 

—  I  Returning _FanlJ)ischargeJh^ssure  is  the  FanlJ)ischarge_Pressure  portion 

~  I  of  Rotorl  object's  state,  in  pounds  per  square  inch 

- 1  Returning J'anl  jyischargeJTemperature  is  the Fanl_Discharge_Temperature portion 

—  I  of  Rotorl  object's  state,  in  degrees  Rankine 

- 1  Returning  J'anl  _Discharge JirJlow  is  the  FanlJ)ischarge_AirJlow  portion 

-- 1  of  Rotorl  object's  state,  in  pounds  per  second 


procedtire  G€t_Turbinel_Discharge_Air_From 
(A_Rotorl :  in  Rotorl; 

Retuming^Turbinel^Discharge^Pressure  :  out  Set. Pressure; 
Retuming_Turbinel_Discharge_Temperature :  out 
Se  t.Temperature ; 

Retuming_Turbinel_Discharge_Air_Flow :  out  SetAir_Flow); 

-I  Description: 

~  I  Initiates  a  report  of  the  specified  Rotorl  object's 

—  I  state  returning  the  Turbine IJischargeJressure, 

—  I  Turbine IJischargeJemperature,  and  the  Turbinel_Discharge_AirJlow. 


—  \  Parameter  Description: 

- 1  AJotorl  identifies  the  Rotorl  whose  state  is  needed. 

—  I  Retuming_Turbi7ielJ)ischarge  Jressure  is  the  Turbine lJ)ischarge_Pres$ure  portion 

- 1  of  Rotorl  object's  state,  in  pounds  per  square  inch 

~  I  Returning JPurhinel  Jischarge  JTemperature  is  the  Turbine IJischargeJTemperature  portion 

—  1  of  Rotorl  object's  state,  in  degrees  Rankine 

~  I  Retuming_TurbinelJ)ischarge_AirJlow  is  the  Turhinel  Jischarge _Air  Jlow  portion 
~  I  of  Rotorl  object's  state,  in  pounds  per  second 


procedure  Get_Rpm_Froin  (A_Rotorl :  in  Rotorl;  Retummg_Rpm  :  out  Set.Rpm); 

—  I  Description: 

—  I  Initiates  a  report  of  the  specified  Rotorl  object's 

—  I  state  returning  the  Rpm. 


—  I  Parameter  Description: 

—  I  AJotorl  identifies  the  Rotorl  whose  state  is  needed. 

—  I  Returning  Jpm  is  the  Rpm  portion 

—  I  of  Rotorl  object's  state,  in  rpm 


procedure  Get_Vibration_Froni  (A_Rotorl :  in  Rotorl; 

Retuming_Vibration :  out  Vibration); 

Description: 

~  I  Initiates  a  report  of  the  specified  Rotorl  object's 

—  I  state  returning  the  Vibration. 

—  I  Parameter  Description: 

~  I  AJotorl  identifies  the  Rotorl  whose  state  is  needed. 

~  I  Returning  Jibration  is  the  Vibration  portion 

—  I  of  Rotorl  object's  state,  in  mils 

pragma  Inline  (Give_Fanl_Inlet_Air_To,  Get_Fanl_Discharge_Air_Froni, 
Give^Turbine l_Inlet_Air_To,  Ge t^Turbine l_Discharge_Air_Froni, 
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Get_Rpm_From,  Get_Vibration_From); 


private 

type  Rotorl^Representation; 

—  incomplete  type,  defined  in  package  body 

type  Rotorl  is  access  Rotor  ^Representation; 

—  pointer  to  an  Rotorl  representation 

end  Rotor  l_Object_Manager; 


C.ll.  Package  Rotor2_Object_Manager 


Module  Name: 

Rotor2_0b ject_Manager 

Module  Type: 

Package  Specification 

Module  Purpome: 

This  package  manages  objects  which  simulate  the 
Engine  Rotor2  for  the  C-141  simulator. 

This  maruigement  entails  creation  of  Rotor2  object* s 
update,  maintenance  of  its  state,  and  state 
reporting  capabilities. 

Module  Deecription: 

The  Rotor2  object  manager  provides  a  means  to  create 
an  Rotor2  object  via  the  New _Rotor2  operation  and  retuj-ns 
an  identification  for  the  Rotor2,  which  is  to  be  used  when 
updating f  accessing  the  Rotor2  object*s  state  as  described  below. 

The  Rotor2  object  manager  provides  a  means  to  update  the 
state  of  the  object  via  the: 

1)  Give _Pan2J[nlet^jAirjro 

2)  Givejrurbine2J[nlet^Airjro 

3)  GiveJTorqueJTo 

operations,  requiring  the  following  external  state  information: 

1)  Fan2_Inlet_Pressure  pounds  per  square  inch 
Fan2J[nletjremperature  degrees  Rankine 

Fan2J[nlet _,Air _Flow  pounds  per  second 

2)  7\irbine2_Inlet_Pres8ure  pounds  per  square  inch 
Turbine2J.nlet ^Temperature  degrees  Rankine 

Turbine2_Inlet _jAir _Flow  pounds  per  second 

3)  TheJTorque  pound  feet 

The  Rotor2  object  manager  provides  a  means  of  obtaining 
state  information  via  the: 

1)  Get_Fan2_Discharge ^ir_From 

2)  Get_Turbine2JDischarge ^ir_From 

3)  Get_Vibration_From 

operations,  yielding  the  following  internal  state  information: 

1)  Fan2  JDischarge_Pressure  pounds  per  square  inch 
Fan2  JDischargeJTemperature  degrees  Rankine 
Fan2_Discharge _jkir_Flow  pounds  per  second 

2)  Turbine2_Discharge_Pressure  pounds  per  square  inch 
Turbine2 JDischargeJTemperature  degrees  Rankine 
Turbine2  JDischarge _,Air _Flow  pounds  per  second 

3)  TheJ/ihration  mils 
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References: 

none 

Design  Documents: 
none 

User’s  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


~  I  ModifictUion  History: 

- 1  24Aug87  cpp  Creation 

-I  I3Jul88  kl  Modified 


Distribution  and  Copyright  Notice: 


Distribution  unlimited 


—  I  No  warranty  is  implied 

Disclaimer: 

—  I  ’This  work  luas  sponsored  by  the  Department  of  Defense,  ** 

with  Standard_Engineering_Type8; 


package  Rotor2_Object_Manager  is 


package  Set  renames  Standard.Engineenng_Type8; 
type  Rotor2  is  private  ; 

~  an  Rotor2  is  an  abstraction  of  a  Rotor2  within  an  Engine. 


type  \^ibration  is  range  0  ..  5; 
—  mils 


function  New_Rotor2  return  Rotor2; 

_ I ««♦«««««««««««««««««««««««««««««««««««««««««««««««««««««««««««*«« 

~l  Description: 

~  I  This  function  returns  a  pointer  to  a  new  Rotor2  object 
~  I  representation.  This  pointer  will  be  used  to  identify 
~  I  the  object  for  state  update  and  stcUe  reporting  purposes. 


Parameter  Description: 

~  1  return  Rotor2  which  is  an  access  to  a  Rotor2  object. 

^  I  «««««««««««««««««««««««««««««««««♦««««««««««««««««««««««««««««««« 


procedure  Give_Faii2_Inlet_Air_To 
(A_Rotor2  :  in  Kotor2; 

Given_Fan2_Inlet_Pressure  :  in  Set.  Pressure; 
Given_Fan2_Inlet_Temperature  ;  in  Set. Temperature; 
Given_Fan2_Inlet_Air_Flow  :  in  Set Air_Flow); 

^ I «««««««««««««*««*««*«*««**««««****««««#«*««*««*««*«##*#*«***«**«* 

—  I  Description: 

~  I  Initiates  a  change  in  the  specified  Rotor2  object’s 

—  I  state  given  the  Fan2_Inlet_Pressure,  Fan2_Inlet_TemperoUure, 

—  I  and  the  Fan2Jnlet __Air_Flow. 
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~l  PcLrameter  Description: 

—  I  A_Rotor2  identifies  the  Rotor2  whose  state  is  to  he  changed. 

- 1  Given _Fan2_InletJPressure  is  the  Inlet  Pressure,  in  pounds 

—  I  per  square  inch 

—  I  Given  J'an2_Inletjremperature  is  the  Inlet  Temperature, 

—  I  in  degrees  Rankine 

—  I  Given  J*an2_Inlet _jA.irJ'low  is  the  Inlet  Air _Flow,  in  pounds 

—  I  per  second 


procedure  Give_Turbine2jnlet_Air_To 
(A_Rotor2  :  in  Rotor2; 

Given_Tiirbine2_Iniet_Pre8sure :  in  SetPressiire; 
Given_Turbine2_Inlet_Temperature  :  in  SetTemperature; 
Given_Turbiiie2_Inlet_Air_Flow ;  in  Set.Air_Flow); 

^  I  ««««««♦«♦«♦«♦«««*♦«♦«««♦«♦«♦«««««««««««««««««««««««««««««««««*««* 

~l  Description: 

—  I  Initiates  a  charge  in  the  specified  Rotor2  objects 

--I  state  given  the  Turbine2_Inlet ^Pressure,  Turbine2_Inlet_Temperature, 

—  I  and  the  Turbine2_Inlet _AirJ'low. 


—  I  Parameter  Description: 

—  I  A_Rotor2  identifies  the  Rotor2  whose  state  is  to  be  changed. 

—  I  Given  jrurbine2_Inlet_Pressure  is  the  Inlet  Pressure, 

~  I  in  pounds  per  square  inch 

—  I  Given jrurbine2jnletjremperature  is  the  Inlet  Temperature, 

~  I  in  degrees  Rankine 

“  I  Given_Turbine2_Inlet _Air _Plow  is  the  Inlet  Air_Flow,  in 

—  I  pounds  per  second 


procedure  Get_Faii2_Discharge_Air_Prom 
(A_Rotor2  :  in  Rotor2; 

Retunnng_Faii2_Di8charge_Pre8sure  :  out  Set. Pressure; 
Retuming_Faii2_Di8charge_Temperature  :  out  Set,  Temperature; 
Retuming,Faii2_Discharge_Air_Flow  :  out  Set,Air_Flow); 

—  I  Description: 

~  I  Initiates  a  report  of  the  specified  Rotor2  object's 

~  I  state  returning  the  Fan2 _Pis<diarge_Pressure, 

~  I  Fan2 _J)ischarge_Teny>erature,  and  the  Fan2 ^Discharge ^MrJ'low. 


Parameter  Description: 

A_Rotor2  identifies  the  Rotor2  whose  state  is  needed. 

Retuming_Fan2 _Pischarge_Pressure  is  the  Fan2_Discharge_Pressure  portion 
of  Rotor2  object's  state,  in  pounds  per  square  in<di 
Retuming_Fan2 J^ischargeJTemperature  is  the  Fan2j)ischargejremperature  portion 
of  Rotor2  object's  state,  in  degrees  Rankine 
Retuming_Fan2  J)ischarge _AirJ'low  is  the  Fan2_Pischarge _Air_Flow  portion 
ofRotor2  object's  state,  in  pounds  per  second 


procedure  Get_Turbme2_Discharge_Air_From 
(A_Rotor2  :  in  Rotor2; 

Retuming_Turbme2_DischaTge_Pre8sure  :  out  SetPressure; 
Retuming_Turbine2_Diacharge_Temperature  :  out 
SeLTemperature; 

Retuming_Turbine2_Discharge_Air_Flow :  out  Set,Air_Flow); 

—  i  Description: 

~  I  Initiates  a  report  of  the  specified  Rotor2  object's 

~  I  state  retumijig  the  7\irbine2jDischarge_Pressure, 

—  I  Turbine2_Discharge_Temperature,  and  the  Turbine2JDischarge^Air_Flow. 


Pctrameter  Description: 
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- 1  AJRotor2  identifies  the  Rotor2  whose  state  is  needed. 

—  I  Retumingjrurbine2_Pischarge_Pressure  is  the  Turhine2_Discharge_Pressure  portion 

—  I  of  Rotor2  object*s  state,  in  pounds  per  square  inch 

—  I  Returning jrurbine2 JDischargeJTemperature  is  the  Turbine2_Dischargejremp€rature  portion 

—  I  of  Rotor2  object* s  state,  in  degrees  Rankine 

—  I  Returning jrurbine2_Discharge_Air_Flow  is  the  Turbine2_Discharge_Air_Flow  portion 

—  I  of  Rotor2  object*s  state,  in  pounds  per  second 


procedure  Get_Vibration_From  (A_Rotor2  :  in  Rotor2; 

Retuming^Vibratioii :  out  \^bration); 

^ I ««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««« 

—  1  Description: 

—  I  Initiates  a  report  of  the  specified  Rotor2  objecVs 

—  I  state  returning  the  Vibration. 


Parameter  Description: 

A_Rotor2  identifies  the  Rotor2  whose  state  is  needed. 

Returning J/ibration  is  the  Vibration  portion 
ofRotor2  object*s  state,  in  mils 

***************************************************************** 


procedure  Give_Torque_To  (A_Rotor2  :  in  Rotor2;  The^Torque  :  in  Set. Torque); 


Description: 

Initiates  a  change  in  the  specified  Rotor2  object* s 
state  given  the  TheJTorque. 


Parameter  Description: 

—  I  A_Rotor2  identifies  the  Rotor2  whose  state  is  to  be  changed. 
- 1  TheJTorque  is  the  Torque,  in  pound  feet  * 

_  I  ««««««««««««««««««««««« 


praipna  Inline  (Give_Fan2_Inlet.jAir_To,  Get_Fan2_Di8charge_Air_Froni, 
Give_Turbine2_Inlet_Air_To,  Get_Turbine2_Di8charge_Air_From, 
Get_Vibration_From,  Give_Torque_To); 


private 

type  Rotor2_Representation; 

—  incomplete  type,  defined  in  package  body 

type  Rotor2  is  access  Rotor2_Representation; 

—  pointer  to  an  Rotor2  representation 

end  Rotor2_Object_Manager; 


C.12.  Package  Flight_Executive 


_ I ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

—  I  Module  Ncune: 

—  I  Flight  Escecutive 


Module  Type: 

Package  Specification 


—  I  Module  Purpose: 

- 1  Executive  for  flight  systems 


104 


CMU/SEI-88-TR.30 


Module  Description: 

TTiis  executive  is  responsible  for  processing  all  flight  systems. 
Processing  involves  handling  all  connections  between  the  flight 
systems  and  processing  each  system. 

References: 

Design  Documents: 
none 

User*s  Manual: 

none 

Testing  and  Validation: 


Notes: 

none 


Modification  History: 
21Aug87  kl  created 


••  I  Distribution  <snd  Copyright  Notice: 

—  t  Distribution  unlimited 

~  I  No  warranty  is  implied, 

~l  Disclaimer: 

—  I  ”This  work  luas  sponsored  by  the  Department  of  Defense, " 

with  Global_Types; 

packag«  Flight.Executive  is 

procedure  Update_Flight_Executive 

(Frame :  in  Global_Types.Execution_Sequence); 

—  I  Description: 

••  I  executive  which  updates  all  flight  systems 

—  \  Parameter  Description: 

~  I  frame  is  the  current  executing  frame 

^ I  ***************************************************************** 

end  Flight_Executive; 


C.13.  Package  body  Flight_Executive 


***************************************************************** 
Module  Name: 

Flight  Executive 

Module  Type: 

Package  Body 


Module  Description: 

This  executive  is  responsible  for  processing  all  flight  systems. 
Processing  involves  handling  all  connections  between  the  flight 
systems  and  processing  each  system. 
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References: 

Design  Documents: 


Testing  and  Validation: 
none 

Notes: 


—  \  Modification  History: 

- 1  21Aug87  kl  created 


—  I  Distribution  and  Copyright  Notice: 

- 1  Distribution  unlimited 

—  I  No  warranty  is  implied. 

—  I  Disclaimer: 

—  I  **This  work  was  sponsored  by  the  Department  of  Defense. " 


with  Flight^System.Names; 

with  Flight_Executive_Coimection_Manager; 

with  Engine.System; 

package  body  Flight_Ezecutive  is 

type  ActiveJn^Frame  is 

array  (Flight_Sy8tein_Name8.Naine_0f_A_Flight_System)  of  Boolean; 

Its_Time_To_Do  :  constant  array  (Global_'iypes.Execution_Sequence)  of 
Active_In_Frame  := 

(Global_Type8.Prame_l_Module8_Are_Executed  => 

(Flight_System_,Name8.Engine  =>  (True),  others  =>  (False)), 

Global_Types.Prame_2_Modules_Are_Executed  => 
(Flight^System.Names.Electrical  =>  (True),  others  =>  (False)), 

Global_Types.Prame_3_Modules_Are_Executed  =>  (others  =>  (False)), 
Global_Types.Prame_4_Modules_Are_Executed  =>  (others  =>  (False)), 

Global_iype8.Frame_5_Module8_Are_Executed  => 
(Flight.Sjrstem^Names.Engine  =>  (True),  others  =>  (False)), 

Global_Types.Frame_6_Modules_Are_Executed  =>  (others  =>  (False)), 
Global_Types.Fraine_7_Modules_Are_Executed  =>  (others  =>  (False)), 
Global_Type8.Frame_8_Modules_Are_Executed  =>  (others  =>  (False))); 


procedure  Update_Flight_Executive  (Frame  :  in 

Global_Types.Execution_Sequence)  is 

—  I  Description: 

—  I  flight  executive.  Performs  process  connections  and  update 

—  I  os  an  atomic  action  for  each  system. 

-I 

—  I  Parameter  Description: 

—  I  frame  is  the  current  executing  frame 

—  I  Notes: 
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—  I  none 


begin 

for  A^System  in  Flight_Syst€m_Names.Name_Of_A_Flight_System  loop 
if  It8_Tijne_To_Do  (Frame)  (A_Syst<^.m)  then 
case  A.System  is 

when  Flight  System  Names.Electrical  => 
nuU; 

when  Flight^System^Names.Engine  => 
Flight_Exe<rutive_Connectioi\_Manager. 

Process_Extemal_Connections_T  o^Engine^System; 
Engine_System.Update_Engine_Syst€m; 

end  case  ; 
end  if; 
end  loop  ; 

end  Updat€_Flight_Exe<rutive; 


begin  —  flight  ^Executive 

null ; 

end  Flight^Executive; 


C.14.  Package  Flight_System_Names 


Module  Name: 

Flight  System  Names 

Module  Type: 

Package  Specification 

Module  Purpose: 

Names  all  systems  under  flight  executive 
Module  Description: 

Provides  the  names  of  all  systems  under  flight  executive. 

References: 

Design  Documents: 
none 

User*s  Manual: 
none 


—  I  Testing  and  Validation: 

~  I  none 

-I  Notes: 

—  I  none 


Modification  History: 
21Aug87  kl  created 


Distribution  and  Copyright  Notice: 
Distribution  unlimited 
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No  warranty  is  implied. 


•A  Disclaimer: 

~  I  "This  work  was  sponsored  by  the  Department  of  Defense. " 

,,  I  **%*4,*m4i**%%i^%***J$tJ$t********************************************** 

package  Flight_System_Names  is 

type  Name_Of_A_Flight_System  is  (Electrical^  Engine); 
type  Aircraft^Engines  is  (Engine_l,  Engine_2,  Engine_3,  Engine_4); 
end  Flight_System_Name8; 


C.15.  Package  Flight_Executive_Connection_Manager 


^  I  *****m*****************m*********** ****************************** 

Module  Name: 

Flight  Executive  Connection  Manager 

Module  Type: 

Package  Specification 

Module  Purpose: 

Describes  and  processes  all  connections  between  flight  systems 


Module  Description: 

This  package  is  responsible  for  proccessing  aU  connections  between 
systems  at  all  levels  within  the  Flight  Executive, 

References: 

Design  Documents: 
none 

XJser^s  Manued: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


ModificcUion  History: 
21Aug87  kl  created 


DistribiUion  and  Copyright  Notice: 
Distribution  unlimited 


—  I  No  warranty  is  implied, 

—  I  Disclaimer: 

~  I  "This  work  was  sponsored  by  the  Department  of  Defense. " 

„  I  ***************************************************************** 


package  Flight_Executive_Connection_Manager  is 

proce dure  Process_Extemal_Connections_T o_Engine_Sy stem; 

_ I  ***************************************************************** 
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—  I  Description: 

—  I  This  procedure  processes  all  connections  between  the  engine 
-- 1  system  and  the  other  systems  at  the  flight  executive  level. 

—  I  Processing  of  connections  means  to  make  the  system  consistent 

—  I  with  its  environment. 

—  I  P ammeter  Description: 

—  I  7wne 

^  I  «««««*«*««**«***********«t**««««t*«4^«r«**«*«***«*««**«*4^4^4^««**«4^«*4^4^ 


end  Flight_Executive_Connection_Manager; 


C.16.  Package  body  Flight_Executive_Connection_Manager 

^  I  *«««*««***«*«************************4^***«*««**«*«*«««4^««4^««««««« 

—  I  Module  Name: 

—  I  Flight  Systems  Connection  Manager 

—  1  Module  Type: 

—  I  Package  Body 


Module  Description: 

The  procedure  below  defines  all  connections  for  passing  data 
between  flight  systems.  Each  connection  is  handled  by  a  procedure 
caU. 


References: 

Design  Documents: 


Testing  and  Validation: 
none 

Notes: 

none 


I  Modification  History: 

—  I  21Aug87  kl  created 


Distribution  and  Copyright  Notice: 
Distribution  unlimited 


—  I  No  warranty  is  implied. 

—  I  Disclaimer: 

—  I  This  work  was  sponsored  by  the  Department  of  Defense. " 

_ I «««*«*«*«*«««**««««««««**«««*««««*«««*«******««****«««**««**««««« 


package  body  Flight_Executive_Connection^Manager  la 


procedure  Process_Extemal_Connections_To_Engine_System  is  separate  ; 


Description: 

This  procedure  processes  all  con/iec^ions  between  the  engine 
system  and  the  other  systems  at  the  flight  executive  level. 
Processing  of  connections  means  to  make  the  system  consistent 
with  its  environment. 
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—  I  PKirameter  Description: 

—  I  none 
-I 

—  I  Notes: 

—  I  none 

^ I **t**********************************4t*************************** 

end  Flight_Executive_Connection_Manager, 


C.17.  Separate  Procedure  body 

Process_Extemal_Connections_To_Engine_System 


Module  Name: 

Process  JlxtemaljConnectionsJToJEngineJSystem 

Module  Type: 

Separate  Procedure  Body 

Module  Pisrpose: 

Process  connections  betioeen  an  engine  system  and  all  external 
systems. 

Module  Description: 

This  procedure  processes  all  connections  between  an  engiTie  system 
and  external  systems.  Processing  of  connections  means  to  make 
the  system  consistent  with  its  environment. 

Parameter  Description: 
none 

References: 

Design  Documents: 
none 

User^s  Manual: 
none 

Testing  and  VcdidcUion: 
none 

Notes: 

none 


Modification  History: 
25Aug87  kl  created 


Distribution  €snd  Copyright  Notice: 


Distribution  unlimited 


—  I  No  warranty  is  implied. 

“I  Disclaimer: 

—  I  *This  work  was  sponsored  by  the  Department  of  Defense. " 

_  I  %4t4t***4t*4t4t**4t'^************************** ************************* 


with  Standard^Engineering^Typea; 
with  Flight_System_Names; 

with  Burner_Object_Manager; 
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with  Engine_Systein_Aggregate; 
with  Rotor2_0bject_Manager; 

separate  (Flight_Executive_Connection__Manager) 

procedure  Process_Extemal_Connections_To_Engine_System  is 

Integrat©d_Drive_Energy  :  Integer; 


—  A  local  variable  is  defined  to  store  the  value  spark  when  it  is  read  from 

—  the  igiution  system.  This  is  a  convention,  described  in  the  SEl  Ada 

—  Coding  Guidelines,  to  restrict  the  spread  of  embedded  function  calls,  Le. 

—  function  calls  as  parameters  within  other  function  calls. 

subtype  Spark.Type  is  Integer  range  0  ..  20; 

Some_Spark  :  Spark^Type; 

The_Bumer_Spark :  Bumer_Object_Manager. Spark; 


function  Spark_Conversion  (In^Spark  :  in  Spark_T3rpe) 
return  B\imer_Object_Manager. Spark  is 

Descrip  Hon: 

This  function  performs  a  type  coni>ersiofi,  //  converts 
the  spark  from  the  Ignition  to  a  spark  that  the 
Burner  jDbject  Jdanager  can  accept.  This  is  done 
as  an  example  of  how  the  type  conversions  can  be  used  to 
connect  objects  which  either  communicate  through  a 
valve  f  regulator,  or  need  different  groins  of  coarseness  of 
the  information. 

In  this  case  we  are  assuming  that  the  Ingition  system 
needs  finer  information  about  the  spark  than  the  Burner. 


—  I  p€uxun€ter  Description: 

—  I  In^Spark  is  the  spark  that  the  Ignition  supplies. 

—  I  return  Spark  is  the  spark  returned  for  the  Burner 

^ j ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦★♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦•• 

begin 

case  In_Spark  is 
when  0  ..  2  => 

RKTURN  Bumer_Object_Manager.None; 
when  3  ..  9  => 

RETURN  Bumer_Object_Manager.Low; 
when  10 ..  20  => 

RETURN  Bumer_Object_Manager.High; 

end  case  ; 

end  Spark^Conversion; 


begin  ‘-Process  JSngine_Connections_To 

“  All  engine  external  connections  are  handled  in  this  procedure. 

—  Each  engine  has  the  same  kind  of  connections,  but  each  engine  is 

—  connected  to  different  instances  of  other  objects.  Thus  all  engines 

—  are  handled  alike  here.  The  different  connections  are  described  by 

—  the  engine jsy stem  jaggregate  package 

for  An^Engine  in  Flight_Sy8tem_Names.Aircraft_Engines  loop 

—  Get _^irJ*rom  (thejenvironment); 

—  Give _Air_To  (ajdiffuser); 

—  goes  here 


Get__Mach_Jiumber_From  (the _air frame); 
Give Jdach _J^umber_To  (ajiiffuser); 
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goes  here 


—  GetJ)ischarge_Pressure_From  (thej:abinj3,ir); 

—  GetJ)ischarge_Pressurp  (thejairjconditioningjsystem); 

—  any  processing  of  these  •’'»<>  -nieces  of  information  goes  here 

—  Give J)ischarge_Pressure_To  {a_hleedjjalve); 

—  goes  here 


—  GetJTorqueJ'rom  (the  Jiydraulicjsystem); 

—  GetJTorque J'rom  (the _oiljsy stem); 

—  GetJTorque J'rom  (the_starterjsystem); 

—  GetJTorque J'rom  (the Jueljsy stem); 

—  GetJTorque J'rom  (the jslectricaljsy stem); 

—  any  processing  of  these  five  pieces  of  information  goes  here 

—  GiveJTorqueJTo  (a_rotor2);  -  ^oc5  here 

—  /or  noio  toe  are  just  showing  one  of  these  five  connections,  the  one 

—  from  the  electrical  system,  for  the  complete  system,  all  five  pieces 

—  of  information  would  be  gathered  and  processed  before  passing  the 

—  information  to  the  Rotor2. 

Integra ted_Drive_Energy  :=  15; 

Rotor2_Object_Manager.Give_Torque_To 
(A_Rotor2  =>  Engine_System^Aggregate. Engines  (An_Engine).The_Rotor2, 
The_Torque  =>  Stan(iaixi_Engineering_iypes. Torque 
(Integra  ted_Drive_Energy)); 


~  Get J'uelJ' low  J'rom  (the  Jueljsy  stem); 

-  GiveJuelJlowJTo  (ajbumer); 

—  goes  here 


--  get  Spark  from  the  Ignition  and  feed  it  to  the  Engine  Burner. 

Some_Spark  :=  15; 

The_B\imer_Spark  :=  Spark_Converaion  (Some_Spark); 

B\imer_Obj  ect_M  anager.  Gi  ve_Spark_To 
(A_B\imer  =>  Engine_System_Aggregate.Engines  (An_Engine).The_Bumer, 
Given^Spark  =>  The_Bumer_Spark); 

end  loop  ; 

end  Process_Extemal_Connections_To_Engine_System; 


C.18.  Package  Engine_System 

—  I  Module  N€sme: 

- 1  Engine JSystem 
-I 

—  I  Module  Type: 

—  I  Package  Specification 
^1 

—  I  Module  Purpose: 

- 1  This  package  contains  the  single  procedure  call  to  update  the 
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simulation  of  an  Engine  System.  It  is  the  sole  interface  to  the  Engines 
from  the  perspective  of  the  executive. 


Module  Description: 

The  siTigle  operation  provided  by  this  package  is  parameterized  with 
the  name  of  the  engine  C/  *>e  updated.  The  operation  accomplishes 
two  sets  of  lower-level  operations: 

-one  to  update  the  state  of  the  objects  at  the  boundries  of  the 
engine  system  which  have  connections  (interfaces)  with  objects 
in  other  systems  external  to  the  engine  system. 

-and  another  to  update  all  objects  internal  to  the  engine  system 
based  on  the  connections  (interfaces)  between  each  other. 

Specifying  the  name  of  the  engine  allows  the  work  to  be  spead  out 
across  the  available  processing  time,  and  pushes  this  decision  up 
to  a  higher,  more  intelligent  being  (the  executive)  to  choose  the 
order  of  updating  the  engines  in  the  engine  system. 

References: 

Design  Documents: 


User*s  Manual: 
none 

Testing  and  Validation: 
none 

Notes: 

none 


Modification  History: 

21AUG87  CPP  Creation 

Distribution  and  Copyright  Notice: 

Distribution  unlimited 

No  warranty  is  implied. 

Disclaimer: 

**This  work  was  sponsored  by  the  Department  of  Defense." 


package  Engine.System  is 

procedure  Update_Engiiie_Systein; 

Description: 

Allows  the  simulation  of  the  Engine  System  to  be  updated 
and  made  consistent.  Then  other  systems  dependent  upon 
the  Engine  System  can  access  the  consistejit  state  of  the 
Engine  System.  It  is  an  atomic  action. 

Parameter  Description: 

Given_Engine_Name 

It's  type  is  declared  in  FlightJSystem JNames  and  is  used 
to  allow  a  higher,  more  intelligent  being  (the  executive)  to 
choose  the  order  of  updating  the  engines  in  the 
engine  system. 


end  Engine^System; 
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C.19.  Package  body  Engine_System 


^ I «««««««««««*««««««««««««««««««««««««««««««««««««««««««««««««««««« 

—  I  Module  Name: 

—  I  Engine  ^System 


Module  Type: 
Package  Body 


Module  Description: 

The  operation  provided  by  this  package  allows  the  ’"user**  to 
update  the  state  of  an  engine,  Le,  update  the  state  of  the 
objects  which  simulate  the  individual  parts  of  the  engine. 

Because  this  system  is  at  the  level  above  the  object 
managers,  we  have  decided  that  the  system  will  internally 
implement  the  conection  manager  at  this  level  since  we  don't 
have  to  go  around  and  touch  the  object  maTiagers  and  tell  them 
to  update  themselves.  The  object  managers  update  themselves 
(thier  state)  when  the  connection  is  made  and  the  state 
information  is  given  to  them. 


References: 

Design  Documents: 
Engine  Object  Diagram. 

Testing  tmd  Validation: 


Notes: 

THIS  IS  NOT  A  FULL  IMPLEMENTATION!!! 

The  code  is  done  to  demonstrate  the  process  of  connecting  objects 
in  a  system 

The  connection  manager  wasn't  implemented  at  this  level 
for  the  reasons  stated  above  in  the  Module  Description. 

Once  the  Engine  system  has  been  updated,  Le.,  it's  state 
made  consistent,  any  objects  whose  state  is  needed  by  objects 
in  other  systems  can  be  had  by  directly  accessing  the  object 
and  getting  it's  state. 

All  internal  routines  preform  a  type  conversion  on  the  data 
when  the  data  is  transfered  from  engirie  object  to  engine  object. 

This  is  done  to  allow  flexibility  and  greater  potential  for  retise 
of  object  managers.  Another  reason  for  type  conversions,  which 
is  related  to  the  flexibility  issue,  is  that  there  may  be  something 
to  model  at  the  connection  between  the  objects,  i.e.  a  valve, 
regulator,  etc.,  for  which  an  object  manager  is  not  necessary. 
Therefore,  any  calculations  or  transformations  which  need  to  occur 
and  be  modelled  at  the  connection  can  be  made  when  the  connection 
between  the  objects  occur. 


Modification  History: 

24AUG87  cpp  Creation 


Distribution  and  Copyright  Notice: 
Distribution  unlimited 


No  warranty  is  implied 
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—  I  Disclaimer: 

—  I  'T/iw  work  was  sponsored  by  the  Department  of  Defense.  ” 

-I 

..  I  ***************************************************************** 


with  Stand ard_Engineering_Types; 
with  Flight_System_Names; 

with  Engine_S3rstem_Aggregate; 
with  Difi\iser_Object_Manager; 
with  Engine_Casing_Object_Manager, 

package  body  Engine.System  is 


procedure  Update_Engine_System  i» 

.. I ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

--I  Description: 

—  I  Allows  the  simulation  of  the  Engine  System  to  be  updated 
-- 1  and  made  consistent.  Then  other  systems  dependent  upon 

—  I  the  Engine  System  can  access  the  consistent  state  of  the 

—  I  Engine  System,  It  is  an  atomic  action. 

—  I  The  object  managers  which  simulate  the  various  parts  of  the 

—  I  engine^  thus  comprising  the  engine  system,  are 

—  I  needed  to  update  the  system's  state  are  the  following: 

—  I  Diffuser jObject  JAanager 

—  I  RotorljObject  _}Aanager 

—  I  Fan_J)uctjybjectJAanager 

—  I  Rotor2_Object_Ma7iager 

—  I  Burner _Object_Manager 

—  I  Exhaust  jObject_Manager 

-- 1  Engine _Casing_Object_Manager 

~  I  The  connections  between  these  dejects  and  the  state  information 

—  I  flowing  between  the  objects  were  derived  solely  from  the 

—  I  Engine  Physical  Model  Diagram  in  ???. 


Parameter  Description: 

Given_Engine_J^ame 

It's  type  is  declared  in  Engine J^ames  and  is  used  to  allow 
a  higher,  more  intelligent  being  (the  executive)  to 
choose  the  order  of  updating  the  engines  in  the 
engine  system. 


—  I  Note: 

—  I  This  routine  models  the  connection  manager  for  this  level. 

^ I  ***************************************************************** 


Difhis©r_Discharge_Pres8iire  :  Standard_Engineering_T3rpes .Pressure; 
Difiuser^Discharge^Temperature  :  Standard_Engineering_Types. Temperature; 
Difiuser_Di8charge_Air_Flow :  Standard_Engineering_Types.Air_Flow; 

begin 

for  An^Engine  in  Flight_SyBtem_Names.Aircrafl_Engines  loop 

—  Model  the  connection  characterized  by  the  dependence  of  the 
—  Engine  Casing  on  the  Diffuser  for  Pneumatic _Energy. 

Difluser_Obj  ect_Manager .  Get_Discharge_Air_From 
(A_DiSuser  => 

Engine_Sy8tem_Aggregate .Engines  (An_Engine).The_Difiuser, 
Retuming_Discharge_Pressure  =>  Diffu8er_Discharge_Pressure, 
Retuming_Discharge_Temperature  => 

Difiu8er_Discharge_Temp  er  ature, 

Retuming_Discharge_Air_Flow  =>  Difiuser_Di8charge_Air_Flow); 
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Engine_Casing_Object_Manager.Give_Inlet_Air_Flow_To 
(A_Engine_Casing  =>  Engine_System_Aggregate.Engines  (An_Engine). 
The_Engiiie_Casing, 

Given_Inlet_Air_Flow  =>  DifTuser_Discharge_Air_Flow); 


end  loop  ; 

end  Update_Engine_Systeni; 
end  Engine.System; 


C.20.  Package  Engine_System_Aggregate 


♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 
Module  Name: 

Engine  _Sy  stem  _fiiggregate 

Module  Type: 

Package  Specification 

Module  Purpose: 

This  package  names  the  TurboRotorl  Engines  and  their  parts. 
Module  Description: 

A  TurboRotorl  Engine  is  an  aggregate  of  parts: 

Diffuser, 

Rotorl, 

Fan J)uct, 

Rotor2, 

BleedJ/alve, 

Burner, 

Exhaust, 

Engine  jCasing. 

The  parts  of  a  TurboFanl  Engine  are  objects  which  have  state 
and  suffer  actions.  Each  part  is  managed  by  it's  own  object 
manager.  This  package  builds  the  four  engines  by  calling  on 
the  various  object  managers  to  create  the  parts.  It  then  stores 
references  to  the  parts  in  a  constant  array  indexed  by  the 
Aircraft  Jlngines,  The  constant  array 

is  created  when  the  package  is  elaborated.  The  constant  array  is 
called  Engines,  A  part  of  an  Engine  is  referenced  as: 

Engines(Engine_Name).  The_<part_kind> 

For  example,  the  Rotorl  of  the  second  Engine  is: 

Engines(Engine  Jl).The _Rotorl 


References: 

Design  Documents: 


User*s  Manual: 
none 

Testing  and  Validation: 
none 


—  I  Notes: 

—  I  Optimizations  which  were  implemented:  the  initialization  of  Engines 
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occurs  at  the  declaration  of  the  Object  instead  of  the  body  because 
the  number  of  engines  and  the  parts  shouldn*t  change^  thus  the  object 
was  also  made  to  be  constant  array  of  Engines. 


—  I  Modification  History: 

—  I  20APR87  CPP  Creation 


—  I  Distribution  cmd  Copyright  Notice: 

—  I  Distribution  unlimited 


No  warranty  is  implied. 


Disclaimer: 

*'This  work  was  sponsored  by  the  Department  of  Defense. " 


with  Flight_System_Names; 


with  Bleed_Valve_Object_Manager; 
with  Bximer_Object_Manager; 
with  Difiiaser^Object^Manager; 
with  Engine_Casmg_Object_Manager, 
with  Exhau8t_0bject_Manager, 
with  Fan_Duct_Object_Manager; 
with  Rotorl_Object_Manager; 
with  Rotor2_Object_Manager; 


package  Engine_S3r8tem_Aggregat6  is 


type  Engine.Representation  is 
record 

—  Defines  an  engine  representation  as  consisting  of: 

The_Diffuser :  DifFuser_Object_Manager.Diffuser, 

The_Rotorl :  Rotor l_Object_Manager.Rotorl; 

The_Fan^Duct :  Fan_Duct_Object_Manager.Fan_Duct; 

The_Rotor2  :  Rotor2_Object_Manager.Rotor2; 

The_Bleed_Valve  :  Bleed_Valve_Object_Manager.Bleed_Valve; 
The^Bumer :  Bumer^Object^Manager.Bumer; 

The.Exhauat :  Exhaust_0bgect_Manager.Ezhau8t; 

The_Engme_Caaing  :  Engine_Ca8ing_0bject_Manager.Engiiie_Casmg; 
end  record  ; 


Engines  :  constant  array  (Flight_SyBtem_Names.Aircraft_Engines)  of 
Engine_Representation  := 

—  Defines  a  constant  array  which  holds  all  4  engines  in  the  system 

—  and  initializes  them  (Le.  all  their  parts) 

(Flight_Sy8tem_Namea.Engine_l  => 

(The^EKfiiaser  =>  DifiTaser_Object_Manager.New_Diffuser, 

The_Rotorl  =>  Rotor l_Object_Manager.New_Rotorl, 

The_Fan_Duct  =>  Fan_Duct_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_Bumer  =>  Bumer_Object_Manager.New_Bumer, 

The_Exhaust  =>  Exhau8t_Object_Manager.New_Exha\ist, 
The_Engine_Casing  => 

Engine_Casing_Object_Manager.New_Engine_Casing), 

Flight_Sy8tem_Namea.Engine_2  => 

(The_DifiTi8er  =>  DijGftiser_Object_Manager.New_Diffuser, 

The_Rotorl  =>  Rotorl_Object_Manager.New_Rotorl, 

The_Fan_Duct  =>  Fan_Duct_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Valve  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_Bumer  =>  Bumer_Object_Manager.New_Bumer, 
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The_Exhauist  =>  Exhaust_Object_Manager.New_Exhaust, 
The_Engine_Casing  => 

Engine_Casing_Obj  ect_Maiiager.  New_Engine_Caising), 

Flight_System_Names.Engine_3  => 

(The_Difi\iser  =>  DifiFuser_Object__Manager.New_DifFiiser, 

The_Rotorl  =>  Rotor l_Object_Manager.New_Ro tori, 

The_Fan_Duct  =>  Fan_Duct_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Vaive  =>  Bleed_Valve_Object_Maiiager.New_Bleed_Valve, 
The_Bumer  =>  B\imer_Object_Manager.New_Bumer, 

The_Exha\iat  =>  Exhaust_Object_Manager.New_Exha\ist, 
The_Engme_Casmg  => 

Engme_Casii5g_Obj  ect_Manager.New_Engine_Casmg), 

Flight_System_Naines.Engine_4  => 

(The_Difl\iser  =>  Difiuser_Object_Manager.New_Diffuser, 

The_Rotorl  =>  Rotor l_Object_Manager.New_Rotorl, 

The^Fan.Ehict  =>  Fan_Duct_Object_Manager.New_Fan_Duct, 
The_Rotor2  =>  Rotor2_Object_Manager.New_Rotor2, 
The_Bleed_Vaive  =>  Bleed_Valve_Object_Manager.New_Bleed_Valve, 
The_Bumer  =>  B\imer_Object_Manager.New_Bumer, 

The_Exhaust  =>  Exhaust_0bject_Manager.New_Exhau3t, 
The_Engine_Casing  => 

Engine^Ca  sing_Obj  ect_Manager.  N  ew_Engine_Casing)); 
end  Engme_System_Aggregate; 
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